Ingenieria del software 



Ingenieria del software 

Septima edicion 



IAN SOMMERVILLE 



Traduction 

Maria Isabel Alfonso Galipienso 
Antonio Botia Martinez 
Francisco Mora Lizan 
Jose Pascua] Trigueros Jover 

Departamento Ciencia de la Computation e Inteligencia Artificial 
Universidad de Alicante 



PEARSON 




Madrid • Mexico • Santafe de Bogota • Buenos Aires • Caracas • Lima • Montevideo 
San Juan • San Jose • Santiago • Sao Paulo • Reading, Massachusetts « Harlow, England 



INGENIER1A DEL SOFTWARE. Septima edicion 
lui SommerviUe 

PEARSON EDUCACION. S.A.. Madrid. 2005 
ISBN: 84-7829-074-5 
MATERIA: Informatica 681.3 

Formato: 195 X 250 mm Paginas: 712 



Todos los derechos reservados. 

Queda prohibida, salvo exception prevista en la Ley, cualquier forma de reproduction, 
distribution, comunicacion publica y transformation de esta obra sin contar con autorizacion 
de los titulares de propiedad intelectual. La infraction de los derechos mencionados puede ser 
constitutiva de delito contra la propiedad intelectual (arts. 270 y sgts. Codigo Penal)- 

DERECHOS RESERVADOS 

© 2005 por PEARSON EDUCACION, S.A. 

Ribera del Loira, 28 

28042 Madrid (Espana) 

INGENIERIA DEL SOFTWARE. Septima edicion 
Ian SommerviUe 

ISBN: 84-7829-074-5 

Deposito Legal: M-3 1.467-2005 

PEARSON ADD [SON WESLEY es un sello editorial autorizado de PEARSON EDUCACION, S.A. 

© Addison- Wesley Publishers Limited 1982, 1984, Pearson Education Limited 1989. 2001, 2004 
This translation of SOFTWARE ENGINEERING 07 Edition is published 
by arrangement with Pearson Education Limited, United Kingdom 

Equipo editorial: 

Editor: Miguel Martin-Romo 
Tecnico editorial: Marta Caicoya 

Equipo de production: 

Director: Jose Antonio Clares 

Tecnico: Jose Antonio Hernan 
Diseno de cubierta: Equipo de diseno de Pearson Education, S.A. 
Composicion: COPIBOOK, S.L. 
Impreso por: TOP PRINTER PLUS, S. L. L. 



IMPRESO EN ESPANA - PRINTED IN SPAIN 



Este libro ha sido impreso con papel y tintas ecologicos 



PROLOGO V 

Parte I. VISION GENERAL 1 

1. Introduccion 3 

1.1. Preguntas frecuentes sobre la ingenieria del software 5 

1.1.1. 6 Que es software? 5 

1.1.2. ^Que " " ingenieria del software? 6 

1.1.3. ^Cual es la diferencia entre ingenieria del software y 

ciencia de la computacion? .7 

1.1.4. ^Cual es la diferencia entre ingenieria del software e ingenieria de sistemas? . 7 

1.1.5. ,\Que es un proceso del software? 7 

1.1.6. iQue es un modelo de procesos del software? 8 

1.1.7. ^Cuales son los costos de la ingenieria del software? 9 

1.1.8. iQue son los metodos de la ingenieria del software? 10 

1.1.9. -Que es CASE? 11 

1.1.10- ^Cuales son los atributos de un buen software? 11 

1.1.11. ^Cuales son los retos fundamentales que afronta la ingenieria del software? 12 

1.2. Responsabilidad profesional y etica 12 

2. Sistemas socio-tecnicos 19 

2.1. Propiedades emergentes de los sistemas 21 

2.2. Ingenieria de sistemas 23 

2.2.1. Definicion de requerimientos del sistema 24 

2.2.2. Diseno del sistema 26 

2.2.3. Modelado de sistemas 28 

2.2.4. Desarrollo de los subsistemas 29 

2.2.5. Integracion del sistema 30 

2.2.6. H vol lie ion del sistema 30 

2.2.7. Desmantelamiento del sistema 31 



VI indice de contenidos 



2.3. Organizaciones, personas y sistemas informaticos 31 
2.3.1. Procesos organizacionales 32 

2.4. Sistemas heredados 35 

3. Sistemas criticos 39 

3.1. Un sistema de seguridad critico sencillo 41 

3.2. Confiabilidad de un sistema 43 

3.3. Disponibilidad y Habilidad 46 

3.4. Seguridad 50 

3.5. Proteccion 53 

4. Procesos del software 59 

4.1. Modelos del proceso del software 60 

4.1.1. El modelo en cascada 62 

4.1.2. Desarrollo evolutivo 63 

4. 1 .3. Ingenieria del software basada en componentes 64 

4.2. Iteracion de procesos 66 

4.2.1. Entrega incremental 66 

4.2.2. Desarrollo en espiral 68 

4.3. Actividades del proceso 69 

4.3.1. Especificacion del software 69 

4.3.2. Diseno e implementacion del software 71 

4.3.3. Validacion del software 74 

4.3.4. Evolucion del software 75 

4.4. El Proceso Unificado de Rational 76 

4.5. Ingenieria del Software Asistida por computadora 79 
4.5.1. Clasificacion de CASE 79 

5. Gestion de proyectos 85 

5.1. Actividades de gestion 87 

5.2. Planificacion del proyecto ' 88 

5.2.1. El plan del proyecto 89 

5.2.2. Hitos y entregas 90 

5.3. Calendarizacion del proyecto 91 
5.3.1. Graficos de barras y redes de actividades 92 

5.4. Gestion de riesgos 95 

5.4.1. Identificacion de riesgos 97 

5.4.2. Anal is is de riesgos 98 

5.4.3. Planificacion de riesgos 100 

5.4.4. Supervision de riesgos 100 

Parte II. REQUERIMIENTOS 1°5 

6. Requerimientos del software 107 

6.1. Requerimientos funcionales y no funcionales 109 

6.1.1. Requerimientos funcionales 110 

6.1.2. Requerimientos no funcionales • 111 

6.1.3. Los requerimientos del dominio 115 



indice de contenidos VU 

6.2. Requerimientos del usuario 116 

6.3. Requerimientos del sistema 118 
6.3.1. Especificaciones en lenguaje estructurado 120 

6.4. Especificacion de la interfaz 122 

6.5. El documento de requerimientos del software 123 

7. Procesos de la ingenieria de requerimientos 129 

7.1. Estudios de viabilidad 131 

7.2. Obtencion y analisis de requerimientos 132 

7.2.1. Descubrimiento de requerimientos 135 

7.2.2. Etnografia 142 

7.3. Validation de requerimientos 144 
7.3.1. Revisiones de requerimientos 145 

7.4. Gestion de requerimientos 146 

7.4.1. Requerimientos duraderos y volatiles 147 

7.4.2. Planificacion de la gestion de requerimientos 147 

7.4.3. Gestion del cambio de los requerimientos 150 

8. Modelos del sistema 153 

8.1. Modelos de contexto 155 

8.2. Modelos de comportamiento 156 

8.2.1. Modelos de flujo de datos 157 

8.2.2. Modelos de maquina de estados 159 

8.3. Modelos de datos 161 

8.4. Modelos de objetos 164 

8.4.1. Modelos de herencia 165 

8.4.2. Agregacion de objetos 168 

8.4.3. Modelado de comportamiento de objetos 169 

8.5. Metodos estructurados 170 

9. Especificacion de sistemas criticos 175 

9.1. Especificacion dirigida por riesgos 177 

9.1.1. Identificacion de riesgos 178 

9.1.2. Analisis y clasificacion de riesgos 178 

9.1.3. Descomposicion de riesgos 181 

9.1.4. Valoracion de la reduccion de riesgos 182 

9.2. Especificacion de la seguridad 183 

9.3. Especificacion de la proteccion 186 

9.4. Especificacion de la Habilidad del software 188 

9.4.1. Metricas de Habilidad 189 

9.4.2. Requerimientos de Habilidad no funcionales 191 

10. Especificacion formal 197 

10.1. Especificacion formal en el proceso del software 199 

10.2. Especificacion de interfaces de subsistemas 202 

10.3. Especificacion del comportamiento 208 



vili Indice de contenidos 



Parte III. DISENO 217 

11. Diseno arquitectonico 219 

11.1. Decisiones de diseno arquitectonico 222 

11.2. Organizacion del sistema. 224 

11.2.1. El modelo de repositorio 225 

11.2.2. El modelo cliente-servidor. 226 

11.2.3. Ei modelo de capas 227 

11.3. Estilos de descomposicion modular 229 

11.3.1. Descomposicion orientada a objetos 230 

11.3.2. Descomposicion orientada a flujos de funciones 231 

11.4. Estilos de control 232 

11.4.1. Control centralizado 233 

11.4.2. Sistemas dirigidos por eventos 234 

11.5. Arquitecturas de referencia 236 

12. Arquitecturas de sistemas distribuidos 241 

12.1. Arquitecturas multiprocesador. 244 

12.2. Arquitecturas cliente-servidor. 245 

12.3. Arquitecturas de objetos distribuidos 249 
12.3.1. CORBA 252 

12.4. Computacion distribuida interorganizacional 256 

12.4.1. Arquitecturas peer-to-peer. 256 

12.4.2. Arquitectura de sistemas orientados a servicios 258 

13. Arquitecturas de aplicaciones 265 

13.1. Sistemas de procesamiento de datos 268 

13.2. Sistemas de procesamiento de transacciones 270 

13.2.1. Sistemas de informacion y de gestion de recursos 272 

13.3. Sistemas de procesamiento de eventos 276 

13.4. Sistemas de procesamiento de lenguajes 279 

14. Diseno orientado a objetos 285 

14.1. Objetos y clases 288 

14.1.1. Objetos concurrentes 290 

14.2. Un proceso de diseno orientado a objetos 292 

14.2.1. Contexto del sistema y modelos de utilizacion 294 

14.2.2. Diseno de la arquitectura 296 

14.2.3. Identificacion de objetos 297 

14.2.4. Modelos de diseno 299 

14.2.5. Especificacion de la interfaz de los objetos 303 

14.3. Evolucion del diseno 304 

15. Diseno de software de tiempo real 309 

15.1. Diseno del sistema 312 
15.1.1. Modelado de sistemas de tiempo real 314 

15.2. Sistemas operativos de tiempo real 315 

15.2.1. Gestion de procesos 316 



indice de contenidos ;X 



15-3. Sistemas de monitorizacion y control 318 
15.4. Sistemas de adquisicion de datos 323 

16. Diseho de interfaces de usuario 331 

16.1. Asuntos de disefio 335 

16.1.1. Interaccion del usuario 335 

16.1.2. Presentacion de la informacion 338 

16.2. El proceso de disefio de la interfaz de usuario 344 

16.3. Analisis del usuario 345 
16.3.1. Tecnicas de analisis 346 

16.4. Prototipado de la interfaz de usuario 348 

16.5. Evaluacion de la interfaz 350 

Parte IV. DESARROLLO 355 

17. Desarrollo 357 

17.1. Metodos agiles 361 

17.2. Programacion extrema 364 

17.2.1. Pruebas en XP 366 

17.2.2. Programacion en parejas 369 

17.3. Desarrollo rapido de aplicaciones 370 

17.4. Prototipado del software 373 

18. Reutilizacion del software 379 

18.1. El campo de la reutilizacion 382 

18.2. Patrones de disefio 384 

18.3. Reutilizacion basada en generadores 387 

18.4. Marcos de trabajo de aplicaciones 389 

18.5. Reutilizacion de sistemas de aplicaciones 391 

18.5.1. Reutilizacion de productos COTS 391 

18.5.2. Lineas de productos software 394 

19. Ingenieria del software basada en componentes 401 

19-1. Componentes y modelos de componentes 404 

19.1.1. Modelos de componentes 407 

19.1.2. Desarrollo de componentes para reutilizacion 409 

19.2. El proceso CBSE 411 

19.3. Composicion de componentes 414 

20. Desarrollo de sistemas criticos 423 

20.1. Procesos confiables 427 

20.2. Programacion confiable 428 

20.2.1. Informacion protegida 428 

20.2.2. Programacion segura 430 

20.2.3. Manejo de excepciones 432 

20.3. Tolerancia a defectos 435 

20.3.1. Deteccion de defectos y evaluacion de dafios 435 

20.3.2. Recuperacion y reparacion de defectos 440 

20.4. Arquitecturas tolerantes a defectos 441 



X indice de contenidos 



21. Evolucidn del software 447 

21.1. Dinamica de evolucion de los programas 449 

21.2. Mantenimiento del software 451 
21.2.1. Prediccion del mantenimiento 454 

21.3. Procesos de evolucion 456 
21.3.1. Reingenieria de sistemas 459 

21.4. Evolucion de sistemas heredados 461 

Parte V. VERIFICACION Y VALIDACION 469 

22. Verificacion y validacion 471 

22.1. Planificacion de la verificacion y validacion 475 

22.2. Inspecciones de software 477 

22.2.1. El proceso de inspeccion de programas 478 

22.3. Anal isis estatico automatizado 482 

22.4. Verificacion y metodos tommies 485 
22.4.1. Desarrollo de software de Sala Limpia 486 

23. Pruebas del software 491 

23.1. Pruebas del sistema 494 

23.1.1. Pruebas de integracion 495 

23.1.2. Pruebas de entregas 497 

23.1.3. Pruebas de rendimiento 500 

23.2. Pruebas de componentes 501 

23.2.1. Pruebas de interfaces 502 

23.3. Diseno de casos de prueba. 504 

23.3.1. Pruebas basadas en requerimientos 505 

23.3.2. Pruebas de particiones 506 

23.3.3. Pruebas estructurales 509 

23.3.4. Pruebas de caminos 511 

23.4. Automatizacion de las pruebas 513 

24. Validacion de sistemas cnticos 519 

24.1. Validacion de la fiabilidad 521 

24.1.1. Perfiles operacionales 522 

24.1.2. Prediccion de la fiabilidad 523 

24.2. Garantia de la seguridad 526 

24.2.1. Argumentos de segundad 527 

24.2.2. Garantia del proceso 530 

24.2.3. Comprobaciones de seguridad en tiempo de ejecucion 531 

24.3. Valoracion de laproteccion 532 

24.4. Argumentos de confiabilidad y de seguridad 534 

Parte VI. GESTION DE PERSONAL 541 

25. Gestidn de personal 543 

25.1. Seleccion de personal 544 

25.2. Motivacion 547 

25.3. Gestionando grupos 550 



Indice de contenidos X; 

25.3.1. La composicion del grupo 551 

25.3.2. Cohesion 552 

25.3.3. Las comunicaciones del grupo 554 

25.3.4. La organizacion del grupo 555 

25.3.5. Entomos de trabajo 556 

25.4. El Modelo de Madurez de la Capacidad del Personal 558 

26. Estimacion de costes del software 561 

26.1. Productividad 563 

26.2. Tecnicas de estimacion 567 

26.3. Modelado algoritmico de costes 570 

26.3.1. El modelo de COCOMO 572 

26.3.2. Modelos algoritmicos de costes en la planificacion 580 

26.4. Duracion y personal del proyecto 582 

27. Gestion de calidad 587 

27.1. Calidad de proceso y producto 589 

27.2. Garantia de la calidad y estandares 591 

27.2.1. ISO 9000 593 

27.2.2. Estandares de documentacion 594 

27.3. Planificacion de la calidad 596 

27.4. Control de la calidad 597 

27.4.1. Revisiones de la calidad 597 

27.5. Medicion y metricas del software 598 

27.5.1. El proceso de medicion 601 

27.5.2. Metricas de producto 602 

27.5.3. Analisis de las mediciones 604 

28. Mejora de procesos 626 

28.1. Calidad de producto y de proceso .609 

28.2. Clasificacion de los procesos 611 

28.3. Medicion del proceso 613 

28.4. Analisis y modelado de procesos 614 

28.4.1. Excepciones del proceso 618 

28.5. Cambio en los procesos 618 

28.6. El marco de trabajo para la mejora de procesos CMMI 619 

28.6.1. El modelo CMMI en etapas 623 

28.6.2. El modelo CMMI continuo 624 

29. Gestion de configuraciones 627 

29.1. Planificacion de la gestion de configuraciones 630 

29.1.1. Identificacion de los elementos de configuracion 630 

29.1.2. La base de datos de configuraciones 632 

29.2. Gestion del cambio 633 

29.3. Gestion de versiones y entregas 636 

29.3.1. Identificacion de versiones 636 

29.3.2. Gestion de entregas 639 

29.4. Construccion del sistema. 641 



XU indice de contenidos 



29.5. Herramientas CASE para gestion de configuraciones 642 

29.5.1. Apoyo a la gestion de cambios 643 

29.5.2. Soporte para gestion de versiones 643 

29.5.3. Apoyo a la construccion del sistema 644 

Glosario 649 

Bibliografia 661 

indice alfabetico 677 



La primera edicion de este libro de ingenieria del software fue publicadahace 
mas de veinte anos. Aquella edicion fae escritautilizando un terminal de tex- 
to conectado a una minicomputadora (un PDP-1 1) que posiblemente costaba 
cerca de 50.000 $. Yo he escrito esta edicion desde un portatil con conexion 
inalambrica que cuesta menos de 2.000 $ y mucho mas potente que aquel 
PDP-1 1. El software mas comun era el software para mainframes, pero las 
computadoras personales estaban a punto de aparecer. Ninguno de nosotros 
imagino el nivel de difusion que estas iban a tener ni el cambio que este he- 
cho iba a producir en el mundo. 

Los cambios en el hardware en los ultimos veinte anos han sido notables, 
y podria parecerque los cambios en el software han sido igual de significati- 
vos. Ciertamente, nuestra capacidad para construir sistemas grandes y com- 
plejos ha mejorado drasticamente. Nuestros servicios e infraestracturas na- 
cionales — energia, comunicaciones y transporte — dependen de sistemas 
informaticos muy grandes, complejos y fiables. En la construccion de siste- 
mas software se mezclan muchas tecnologias — J2EE, .NET,EJB, SAP, 
BPEL4WS, SOAP, CBSE — que permiten que aplicaciones grandes basadas 
en Web sean desarrolladas mucho mas rapido que en el pasado. 

Sin embargo, a pesar de los cambios que ha habido en las dos ultimas deca- 
das, cuando nosotros miramos mas alia de las tecnologias, hacia los procesos 
fundamentales de la ingenieria del software, estos se han mantenido igual. Nos- 
otros reconocimos hace veinte anos que el modelo en cascada tenia problemas 
serios, pero un examen publicado en diciembre de 2003 por IEEE mostraba que 
mas de un 40% de las companias siguen utilizando esta aproximacion. El tes- 
teo sigue siendo la tecnica de validacion dominante, apesar de que otras tecni- 
cas, como las inspecciones, han sido utilizadas de una forma mas efectiva des- 
de mediados de los anos 70. Las herramientas CASE, a pesar de estar basadas 
ahora en U M L , siguen siendo basicamente editores graficos con alguna fun- 
cionalidad para chequeary generar codigo. 
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Nuestros actuates metodos y tecnicas de ingenieria del software han hecho que lacons- 
truccion de sistemas grandes y complejos seamejor. Apesarde ello, sigue siendo habitual en- 
contrar proyectos que se retrasan, que sobrepasan el presupuesto o que se entregan sin satis- 
facer las necesidades de los clientes. Mientras estaba escribiendo este libro, se divulgo una 
investigacion del gobierno en Reino Unido, sobre un proyecto para proveer a los juzgados de 
un sistema software para casos de delincuencia menor. El coste del sistema fue estimado en 
156 millones de libras y fue planificado para ser entregado en el ano 2001 . En 2004, el coste 
habia subido a 390 millones de libras y no estaba totalmente operativo. Hay, por lo tanto, una 
necesidad imperiosade educacion en ingenieria del software. 

En los liltimos anos, el desarrollo mas significativo en ingenieria del software ha sido la 
aparicion de U M L como estandar para la descripcion de sistemas orientados a objetos, y el 
desarrollo de metodos agiles como la programacion extrema. Los metodos agiles estan per- 
mitiendo el desarrollo rapido de sistemas, explicitamente implican al usuario en el equipo 
de trabajo y reducen el papeleo y la burocracia en el proceso software. A pesar de lo que 
algunos criticos sostienen, pienso que estas aproximaciones encarnan buenas practicas de 
ingenieria del software. Ellas tienen unos procesos bien definidos, prestan atencion a la es- 
pecificacion del sistema y a los requerimientos del usuario, y tienen estandares de alta ca- 
lidad. 

No obstante, esta revision no pretende serun texto sobre metodos agiles. Prefiero centrar- 
me en los procesos basicos de ingenieria del software — especificacion, diseno, implementa- 
cion, verificacion, y validacion y gestion — . Es necesario entender estos procesos y las tecni- 
cas asociadas paradecidir si los metodos agiles son la estrategia de desarrollo mas adecuada 
y como adaptar los metodos a una situacion particular. Un tema dominante en el libro son los 
sistemas criticos — sistemas en los que los fallos de funcionamiento tienen consecuencias ne- 
fastas y donde la seguridad del sistema es critica. En cada parte del libro, estudiaremos las tec- 
nicas especificas de ingenieria del software que son relevantes para la construccion sistemas 
criticos. 

Inevitablemente, los libros reflejan las opiniones y prejuicios de sus autores. Algunos lec- 
tores estaran en desacuerdo con mis opiniones y con mi eleccion del material. Este desacuer- 
do es un reflejo de la diversidad de disciplinas y es esencial para su evolucion. No obstante, 
yo espero que a todos los ingenieros de software y estudiantes de ingenieria del software les 
resulte interesante. 

Estructura del libro 

La estructura del libro estabasada en los procesos fundamentales de la ingenieria del software. 
Esta organizado en seis partes, con varios capitulos en cada parte: 

Parte 1 : Introduce la ingenieria del software, situandola en un amplio contexto de sistemas 
y presentando las nociones de procesos y gestion de ingenieria del software. 
Parte 2: Trata los procesos, tecnicas y documentacion asociados con los requerimientos de 
ingenieria. Incluye un estudio sobre los requerimientos software, modelado de sistemas, 
especificacion formal y tecnicas para especificar la fiabilidad. 

Parte 3: Esta parte esta dedicada al diseno de software y a los procesos de diseno. Tres de 
los seis capitulos se centran en el importante tema de las arquitecturas software. Otros te- 
mas incluyen diseno orientado a objetos, diseno de sistemas en tiempo real y diseno de in- 
terfaces de usuario. 
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Parte 4 : Describe una serie de aproximaciones a la implementacion, incluyendo metodos 
agiles, reutilizacion, CBSE y desarrollo de sistemas criticos. Como los cambios son una 
parte importante de la implementacion, he integrado temas de evoluciony mantenimiento 
en esta parte. 

Parte 5: Se centra en temas deverificaciony validacion. Incluye capitulos de validacion y 
verificacion estatica, testeo y validacion de sistemas criticos. 

Parte 6: La parte final abarca una serie de lemas de gestion: gestion de personal, estima- 
cion de costes, gestion de calidad, procesos de mejora y gestion de cambios. 

En la introduccion de cada parte, expondre la estructura y organizacion con mayor detalle. 



Cambios en la 6.» edicion 



Hay cambios importantes, relativos a la organizacion y contenido, respecto a la edicion pre- 
via. He incluido cuatro capitulosnuevosy he hechouna importante revision enotrosonce ca- 
pitulos. Todos los otros capitulos han sido actualizados, incorporando convenientemente nue- 
vo material. 

Mas y mas sistemas tienen altos requerimientos de disponibilidady fiabilidad, y espero que 
nosotros tomemos la fiabilidad como un conductor basico en la ingenieria del software. Por 
estarazon, los capitulos de sistemas criticos han sido integrados enotras secciones. Paraevi- 
tar que el vo lumen del libro sea excesivo, he reducido la cantidad de material sobre manteni- 
miento del software y he integrado los temas de mantenimiento y evolucion del software en 
otros capitulos. Hay dos casos de estudio — uno sobre la gestion de documentos de unabi- 
bliotecay otro de un sistema medico — , los cuales presento en diferentes capitulos. 

El material referente a los casos de estudio esta senalado con iconos en los margenes. La 
Tabla 1 resume los cambios, indicando con el numero entre parentesis el capitulo correspon- 
diente en la 6r edicion. En el sitio Web del libro se puede encontrar mas informacion sobre 
estos cambios. 

TABLA 1. Revision 
de los capitulos 

Capitulo 13: Arquitectura de las aplicaciones. 

Capftulo 17: Desarrollo rapido de aplicaciones. 

Capitulo 19: Ingenieria del software basada en componentes. 

Capitulo 21: Evolucion del software 



Capitulo 2: Sistemas socio-tecnicos (2) 

Capitulo 4: Procesos software (3) 

Capftulo 7: Procesos de ingenieria de requerimientos (6) 

Capftulo 9: Especif icacion de sistemas criticos (17) 

Capitulo 12: Arquitecturas de sistemas distribuidos (11) 

Capitulo 16: Diseno de interface de usuario (15) 

Capftulo 18: Reutilizacion de codigo (14) 

Capftulo23: Pruebas del software (20) 

Capitulo 25: Gestion de personal (22) 

Capitulo 24: Validacion de sistemas criticos (21) 

Capitulo 28: Mejora de procesos (25) 
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Gin a para el lector 

Este libro esta enfocado a estudiantes, graduados e ingenieros de la industria del software. 
Puede ser utilizado en cursos generales de ingenieria del software o en cursos especificos, 
como programacion avanzada, especificacion, disefio y gestion software. A los ingenieros de 
software que trabajan en la industria, este libro puede resultarles util como lectura general y 
como actualizacion de sus conocimientos en temas particulares como ingenieria de requeri- 
mientos, disefio de la arquitectura, desarrollo de sistemas formales y mejora de procesos. Los 
ejemplos en el texto han sido utilizados como una via practica para reflejar el tipo de aplica- 
ciones que los ingenieros deben desarrollar. 

Usando el libro para ensehar 

He disefiado el libro para que pueda ser utilizado en tres tipos de cursos de ingenieria. 

I. Cursos de introduction a la ingenieria del software para estudiantes que no tienen 
experiencia en ingenieria del software. Se puede empezar con la seccion introducto- 
ria y luego seleccionar capitulos de otras secciones del libro. Esto dara a los estu- 
diantes una vision general de la materia con la oportunidad de hacer un estudio mas 
detallado por parte de los alumnos interesados. Si el curso esta basado en proyectos, 
los primeros capitulos proporcionaran suficiente material para comenzarel proyec- 
to, y capitulos posteriores serviranpara referenciar y dar mas informacion del avan- 
ce de su trabajo. 
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2. Cursos de introduction o nivel medio sobre tentas especificos de ingenieria del soft- 
ware. El libro es valido para cursos de especificacion de requerimientos, diseno de 
software, gestion de proyectos software, desarrollo de sistemas fiables y evolucion del 
software. Cada parte puede servirtanto para cursos de introduccion como intermedios 
en los diferentes temas. As! como cada capitulo tiene lecturas asociadas, he incluido 
en el sitio web informacion sobre otros articulos y libros relevantes. 

3. Cursos avanzados en ingenieria del software. Los capitulos pueden servir como base 
para cursos especificos, pero deben ampliarse con lecturas complementarias que tra- 
ten con mayor detalle los temas. Por ejemplo, yo imparto un modulo en Master en in- 
genieria de sistemas el cual se apoya en este material. He incluido detalles de este cur- 
so y de un curso en ingenieria de sistemas criticos en el sitio web. 

La utilidad de un libro general como este esta en que puede utilizarse en diferentes cursos. 
En Lancaster, nosotros empleamos el texto en un curso de introduccion a la ingenieria del soft- 
ware y en cursos de especificacion, diseno y sistemas criticos. Cursos de ingenieria del soft- 
ware basada en componentes e ingenieria de sistemas utilizan el libro a lo largo de su impar- 
ticion, junto con articulos complementarios que se distribuyen entre los alumnos. Tenerun 
solo libro de texto da a los alumnos una vision coherente de la materia, y estos no tienen que 
comprar varios libros. 

Para reforzar la experiencia de aprendizaje de los estudiantes, he incluido un glosario de 
terminos , con definiciones adicionales en el sitio web. Ademas, cada capitulo tiene: 

• Unos objetivos claros presentados en la primera pagina. 

• Una lista de los puntos clave tratados en el capitulo. 

• Lecturas adicionales recomendadas — otros libros que estan actualmente en impresion o 
articulos facilmente accesibles (en mi sitio web puede encontrarun listado de otras lec- 
turas y enlaces recomendados). 

• Ejercicios, que incluyen ejercicios de diseno. 

El proyecto denominado «Software Engineering Body of Knowledge» ( http://swebok.org) 
fue establecido para definir las areas clave de conocimiento tecnico relevantes para los pro- 
fesionales del software. Estan organizadas bajo 10 epigrafes: requerimientos, diseno, cons- 
truccion, prueba, mantenimiento, gestion de configuraciones, gestion, procesos, herramien- 
tas y metodos, y calidad. Mientras seria imposible incluiren un solo libro de texto todas las 
areas de conocimiento propuestas por el proyecto SWEBOK. en este libro se tratan todas las 
areas de alto nivel. 



Paginas Web 

El sitio web asociado a este libro es: 
http://www.software-engin.com 

Este sitio ofrece una amplia gama de material complementario de ingenieria del software. 
Desde aqui, usted puede acceder a las paginas web de soporte de este libro y de ediciones an- 
teriores. 

Esta ha sido mi politica, en versiones anteriores y en esta, para mantener el numero de en- 
laces web en el libro en un minimo absoluto. La razon es que los enlaces web sufren muchos 
cambios y, una vez impreso el libro, son imposibles de actual;7ar. En consecuencia, lapagi- 
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na web del libro incluye un gran numero de enlaces a recursos y material relacionado con la 
ingenieriadel software. Si usted los utilizay encuentraproblemas, por favor hagamelo saber 
y actualizare esos enlaces. 

Para dar soporte en el uso de este libro en cursos de ingenieria del software, he incluido 
una amplia variedad de material en el sitio web. En los enlaces al material para el docente, 
podra encontrar: 

• Presentaciones (PowerPoint y PDF) para todos los capitulos del libro. 

• Cuestionesparacadacapitulo. 

• Casos de estudio. 

• Sugerencias sobre proyectos. 

• Descripciones sobre estructuras de cursos. 

• Sugerencias sobre lecturas complementarias y enlaces a los recursos web de cada capi- 
tulo. 

• Soluciones para los ejercicios asociados a cada capitulo y para las cuestiones (solo pro- 
fesor). 

Sus sugerencias y comentarios sobre el libro y el sitio web seran bienvenidos. Puede con- 
tactar conmigo a traves de ianiSjsoftware-engin.com . Recomiendo que incluya [SE7] en el 
asunto del mensaje para evitar que los filtros antispam rechacen su mensaje. Siento no tener 
tiempo para ayudar a los estudiantes en su trabajo; por lo tanto, no me pregunten como re- 
solver ningiin problema del libro. 

Reconocimientos 

A lo largo de los anos muchas personas han contribuido al desarrollo de este libro, y me gus- 
taria dar las gracias a lodos los que han comentado las ediciones anteriores y han hecho su- 
gerencias constructivas (revisores, estudiantes, lectores que me han escrito). Al personal de 
la editorial y produccion de Pearson Educacion en Inglaterray en Estados Unidos por su apo- 
yo y ayuda, y producir el libro en un tiempo record. Por lo tanto, gracias a Keith Mansfield, 
Patty Mahtani, Daniel Rausch, Carol Noble y Sharon Burkhardt por su ayuda y apoyo. 

Finalmente, me gustaria dar las gracias a mi familia, que ha tolerado mi ausencia cuando 
el libro estaba comenzandose a escribir y mi frustracion cuando las palabras no surgian. Y en 
especial a mi esposa, Anne, y a mis hijas, A 1 i y Jane, por su ayuda y apoyo. 



Ian Sommerville, 
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1 GENERAL 



Capi'tulo 1 Introduction 

Capitulo 2 Sistemas socio-tecnicos 

Capitulo 3 Sistemas criticos 

Capi'tulo 4 Procesos del software 

Capitulo 5 Gestion de proyectos 



La estructura basica de este libro sigue los procesos esenciales del software de especifi- 
cacion, diseno, desarrollo, verificacion y validacion, y gestion. Sin embargo, mas que caer 
inmediatamente en estos temas, he incluido esta seccion de vision general para que 
pueda tener una idea amplia de la disciplina. Esta parte comprende los cinco primeros 
capitulos: 

El Capitulo 1 es una introduction general a la ingenieria del software. Para hacerlo ac- 
cesible y facil de entender, lo he organizado usando una estructura de pregunta/res- 
puesta donde planteoyrespondo preguntas tales como «<,Que es la ingenieria del soft- 
ware?". Tambien introduzco el profesionalismo y la etica en este capitulo. 

El Capitulo 2 presenta los sistemas socio-tecnicos, un tema que creo es absoluta- 
mente esencial para los ingenieros de software. El software nunca es usado por si solo, 
pero siempre es parte de un sistema mayor que incluye el hardware, el elemento hu- 
mano y, a menudo, las organizaciones. Estos componentes influyen prof undamente en 
los requerimientos y f uncionamiento del software. En este capitulo se estudian las pro- 
piedades emergentes de los sistemas, los procesos de la ingenieria de sistemas y algu- 
nas de las formas en las que los asuntos organizacionales y humanos afectan a los sis- 
temas de software. 

El Capitulo 3 trata los «sistemas critlcos». Los sistemas criticos son sistemas en los que 
un fa Ho de funcionamiento del software tiene graves consecuenciastecnicas, economi- 
cas o humanas, y en los que la seguridad del sistema, la proteccion y la disponibilidad 
son requerimientos clave. Se incluyen capitulos sobre aspectos de sistemas criticos en 
cada parte del libro. En este capitulo, ademas, presento el primero de los casos de es- 
tudio del libro: el software para una bomba de insulina usado en el tratamiento de pa- 
cientes diabeticos. 

Los tres primeros capitulos establecen el escenario de la ingenieria del software y el 
Capitulo 4 continua con este propdsito introduciendo el proceso del software y los mo- 
delos de procesos del software. Introduzco procesos basicos de la ingenieria del soft- 
ware, la materia del libro, en este capitulo. Tambien trato brevemente el Proceso Unifi- 
cado de Rational, el cual esta enfocado al desarrollo de sistemas orientados a objetos. 
La ultima seccion del capitulo explica como los procesos del software pueden ser apo- 
yados con herramientas software automatizadas. 

El Capitulo 5 aborda la gestion de proyectos. La gestion de proyectos es parte de to- 
dos los desarrollos profesionales de proyectos, y aqui describo la planif icacion del pro- 
yecto, la confeccion de agendasy la estimation de riesgos. Los estudiantes de un curso 
de ingenieria del software implicados en un proyecto estudiantil deberian encontrar aqui 
la information que necesitan para trazar graf icos de barras para un programa del pro- 
yecto y para la asignacion de recursos. 



1 A 

Introduction 



Objetivos 

Los objetivos de este capitulo son introducir la ingenieriadel 
software y proporcionar un marco para entender el resto del libro. 
Cuando haya leido este capitulo: 

• comprendera que es la ingenieria del software y por que es 
importante; 

• conocera las respuestas a las preguntas clave que 
proporcionan una introduccion a la ingenieria del software; 

• comprendera algunos aspectos profesionales y de etica que 
son importantes para los ingenieros de software. 

Contenidos 

1.1 Preguntas frecuentes sobre la ingenieria del software 

1.2 Responsabilidad profesional y etica 
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Actualmente casi todos los paises dependen de complejos sistemas informaticos. Infraes- 
tructuras nacionales y utilidades dependen de sistemas informaticos, y la mayor parte de los 
productos electricos incluyen una computadoray software de control. La fabricacion indus- 
trial y distribucion esta completamente informatizada, como el sistema financiero. Por lo tan- 
to, producir software costeable es esencial para el funcionamiento de la economia nacional 
e internacional. 

La ingenieria del software es una disciplina de la ingenieria cuya meta es el desarrollo cos- 
teable de sistemas de software. Este es abstracto e intangible. No esta restringido por mate- 
riales, o gobernado por leyes fisicas o por procesos de manufactura. De alguna forma, esto 
simplifica la ingenieria del software ya que no existen limitaciones fisicas del potencial del 
software. Sin embargo, esta falta de restricciones naturales significa que el software puede lie- 
gar a ser extremadamente complejo y, por lo tanto, muy dificil de entender. 

La nocion de ingenieria del software file propuesta inicialmente en 1968 en una conferen- 
ciapara discutir lo que en ese entonces se llamo la«crisis del software)). Esta crisis del soft- 
ware fue el resultado de la introduccion de las nuevas computadoras hardware basadas en cir- 
cuitos integrados. Su poder hizo que las aplicaciones hasta ese entonces irrealizables fueran 
una propuesta factible. El software resultante fue de ordenes de magnitud mas grande y mas 
complejo que los sistemas de software previos. 

La experiencia previa en la construccion de estos sistemas mostro que un enfoque informal 
para el desarrollo del software no era muy bueno. Los grandes proyectos a menudo tenian afios 
de retraso. Costaban mucho mas de lo presupuestado, eran irrealizables, dificiles de mante- 
nery conundesempeflopobre. El desarrollo de software estaba en crisis. Los costos del hard- 
ware se tambaleaban mientras que los del software se incrementaban con rapidez. Se necesi- 
taban nuevas tecnicas y metodos para controlar la complejidad inherente a los sistemas 
grandes. 

Estas tecnicas han llegado a ser parte de la ingenieria del software y son ampliamente uti- 
lizadas. Sin embargo, cuanto mas crezca nuestra capacidad para producir software, tambien 
lo hara la complejidad de los sistemas de software solicitados. Las nuevas tecnologias resul- 
tantes de la convergencia de las computadoras y de los sistemas de comunicacion y comple- 
jas interfaces graficas de usuario impusieron nuevas demandas a los ingenieros de software. 
Debido a que muchas companias no aplican de forma efectiva las tecnicas de la ingenieria del 
software, demasiados proyectos todavia producen software que es irrealizable, entregado tar- 
de y sobrepresupuestado. 

Se puede afirmar que hemos hecho enormes progresos desde 1968 y que el desarrollo de 
esta ingenieria ha mejorado considerablemente nuestro software. Comprendemos mucho me- 
jor de las actividades involucradas en el desarrollo de software. Hemos desarrollado metodos 
efectivosdeespecificacion, disenoe implementaciondel software. Las nuevas notacionesy 
herramientas reducen el esfuerzo requerido para producir sistemas grandes y complejos. 

Ahora sabemos que no hay una enfoque «ideal» a la ingenieria del software. La ampliadi- 
versidad de diferentes tipos de sistemas y organizaciones que usan estos sistemas significa que 
necesitamos una diversidad de enfoques al desarrollo de software. Sin embargo, las nociones 
fundamentales de procesos y la organizacion del sistema son la base de todas estas tecnicas, 
y estas son la esencia de la ingenieria del software. 

Los ingenieros de software pueden estar orgullosos de sus logros. Sin software complejo 
no habriamos explorado el espacio, no tendriamos Internet y telecomunicaciones modernas, 
y todas las formas de viajar serian mas peligrosas y caras. Dicha ingenieriaha hecho enormes 
contribuciones, y no cabe dudad de que, en cuanto la disciplina madure, su contribucion en el 
siglo xx i sera aun mas grande. 
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1.1 Preguntas frecuentes sobre la ingenieria del software 

Esta seccion se ha disenado para resolver algunas preguntas fundamentales sobre la ingenie- 
ria del software y para proporcionar algunosde mispuntos de vista sobre ladisciplina. Elfor- 
mato que he utilizado es el de «lista de preguntas frecuentes». Este enfoque se empleaco- 
munmente en los grupos de noticias de Internet para proveer a los recien llegados de las 
respuestas a las preguntas frecuentes. Creo que es una manera muy efectiva de dar una intro- 
duccion sucinta al tenia de la ingenieria del software. 

Las preguntas que se contestan en esta seccion se muestran en la Figura 1.1. 

1.1.1 iQue es software? 

Muchas personas asocian el termino software con los programas de computadora. Sin em- 
bargo, yo prefiero una definicion mas amplia donde el software no son solo programas, sino 
todos los documentos asociados y la configuracion de datos que se necesitan para hacer que 
estos programas operen de manera correcta. Por lo general, un sistema de software consiste 
en diversos programas independientes, archivos de configuracion que se utilizan para ejecu- 



iQue es software? 



Programas de ordenador y la documentation asotiada. los pfoductos de software se 
pueden des* miliar para algun diente en particular o para un mercado general. 



iQue es la ingenieria del software? 



La ingenieria del software es una distipfina de ingenieria que comprende todos los 
aspectos de la production de software. tCuAl es la dtferentia entre ingenieria del soft- 
ware y cientia de la computati6n? La cientia de fa computation comprende fa teoria 
y los fundamentos; la ingenieria del software comprende las fbrmas practices para 
desarralfar y entregar un software util. iCual es la diferentia entre ingenieria del soft- 
ware e ingenieria de sistemas? La ingenieria de sistemas se refiere a todos los as- 
pectos del desarrollo de sistemas informiticos, induyendo hardware, software e in- 
genieria de procesos. La ingenieria del software es parte de este proceso. 



tQue es un proceso del software? Un conjunto de actividades cuya meta es el desarrollo o evolution del software. 

i.Que es un modelo de procesos 
del software? 



Una representatidn simplificada de un proceso del software, presentada desde una 
perspectiva especfSca. 



i Guiles son los costos de la ingenieria 
del software? 



A grandes rasgos, el 60 % de los costos son de desarrollo, el 40% restante son de 
pruebas. En el caso def software personalizado, Ids costos de evolution a menudo 
exceden los de desarrollo. 



i.Que son los metodos de la ingenieria 
del software? 



Enfoques estructurados para el desarrollo de software que induyen modelos de sis- 
temas, notationes, reglas, sugerentias de diseno y gulas de procesos. 



iQue es CASE (Ingenieria del Software 
Asistida por Ordenador)? 



Sistemas de software que intentan proporcionar ayuda automatizada a las activida- 
des del proceso del software. Los sistemas CASE a menudo se utilizan como apoyo 
almetodo. 



iCuales son los atributos de un buen 
software? 



El software debe tener la funtionaltdad y el rendimiento requeridos por el usuario, 
ademas de ser mantenible, confiable y ficil de urjlrzar. 



iCuales con los retos fundamentales 
a los que se enfrenta ta ingenieria 
de software? 



Enfrenta rse con la credente diversidad, las demandas para redutir h» tempos de en- 
trega y el desarrollo de software fiable. 



Figura 1.1 Preguntas frecuentes sobre la ingenieria del software. 
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tar estos programas, un sistema de documentacion que describe la estructura del sistema, la 
documentacion para el usuario que explica como utilizarel sistema y sitios web que permi- 
tan a los usuarios descargar la informacion de productos recientes. 

Los ingenieros de software se concentran en el desarrollo de productos de software, es de- 
cir, software que se vende a un cliente. Existen dos tipos de productos de software: 

1. Producios genericos. Son sistemas aislados producidos por una organizacion de des- 
arrollo y que se venden al mercado abierto a cualquier cliente que le sea posible com- 
prarlos. Ejemplos de este tipo de producto son el software para PCs tales como bases de 
datos, procesadores de texto, paquetes de dibujo y herramientas de gestion de proyectos. 

2. Productos personalizados (o hechos a medida). Son sistemas requeridos porun clien- 
te en particular. Un contratista de software desarrolla el software especialmente para 
ese cliente. Ejemplos de este tipo de software son los sistemas de control para instru- 
mentos electronicos, sistemas desarrollados para llevar a cabo procesos de negocios 
especificos y sistemas de control del trafico aereo. 

Una diferencia importante entre estos diferentes tipos de software es que, en los produc- 
tos genericos, la organizacion que desarrolla el software controla su especificacion. La espe- 
cificacion de los productos personalizados, por lo general, es desarrollada y controlada por la 
organizacion que compra el software. Los desarroIJadores de software deben trabajarcon esa 
especificacion. 

No obstante, la linea de separacion entre estos tipos de productos se esta haciendo cada 
vez mas borrosa. Cada vez mas companias de software empiezan con un sistema generico y 
lo adaptan a las necesidades de un cliente en particular. Los sistemas de planificacion de re- 
cursos empresariales (ERP), como los sistemas SAP, son el mejor ejemplo de este enfoque. 
Aqui, un sistema largo y complejo se adapta a una compaftia incorporando informacion so- 
bre reglas de negocio y de procesos, informes, etcetera. 

1.1.2 iQue es la Ingenieria del software? 

La ingenieria del software es una disciplina de la ingenieria que comprende todos los aspec- 
tos de la produccion de software desde las etapas iniciales de la especificacion del sistema, 
hasta el mantenimiento de este despues de que se utiliza. En esta definicion, existen dos Era- 
ses clave: 

1. Disciplina de la ingenieria. Los ingenieros hacen que las cosas funcionen. Aplican 
teorias, metodos y herramientas donde sean convenientes, pero las utilizan de forma 
selectiva y siempre tratando de descubrir soluciones a los problemas, aun cuando no 
existan teorias y metodos aplicables para resolverlos. Los ingenieros tambien saben 
que deben trabajar con restricciones financieras y organizacionales, por lo que buscan 
soluciones tomando en cuenta estas restricciones. 

2. Todos los aspectos de produccion de software. La ingenieria del software no solo 
comprende los procesos tecnicos del desarrollo de software, sino tambien con activi- 
dades tales como la gestion de proyectos de software y el desarrollo de herramientas, 
metodos y teorias de apoyo a la produccion de software. 

En general, los ingenieros de software adoptan un enfoque sistematico y organizado en 
su trabajo, ya que es la forma mas efectiva de producir software de alta calidad. Sin embar- 
go, aunque la ingenieria consiste en seleccionar el metodo mas apropiado para un conjunto 
de circunstancias, un enfoque mas informal y creativo de desarrollo podria serefectivo en al- 
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gunas circunstancias. El desarrollo informal es apropiado para el desarrollo de sistemas ba- 
sados en Web, los cuales requieren una mezcla de tecnicas de software y de diseno grafico. 

1.1.3 &Cual es la dlferencla entre ingeniena del software y clencla 
de la computacldn? 

Esencialmente, la ciencia de la computacion se refiere a las teorias y metodos subyacentes a 
las computadoras y los sistemas de software, mientras que la ingenieria del software se refie- 
re a los problemas practicos de producir software. Los ingenieros de software requieren cier- 
tos conocimientos de ciencia de la computacion, de la misma forma que los ingenieros elec- 
tricos requieren conocimientos de fisica. 

Lo ideal seriaque todos los ingenieros de software conocieran las teorias de la ciencia de 
la computacion, pero en realidad este no es el caso. Los ingenieros de software a menudo uti- 
lizan enfoques ad hoc para desarrollar el software. Las ingeniosas teorias de la ciencia de la 
computacion no siempre pueden aplicarse a problemas reales y complejos que requieren una 
solucion de software. 

1.1.4 iCual es la dlferencla entre Ingenieria del software e Ingenieria 
de sistemas? 

La ingenieria de sistemas se refiere a todos los aspectos del desarrollo y de la evolucion de 
sistemas complejos donde el software desempena un papel principal. Por lo tanto, la ingenie- 
ria de sistemas comprende el desarrollo de hardware, politicas y procesos de diseno y distri- 
bucion de sistemas, asi como la ingenieria del software. Los ingenieros de sistemas estan in- 
volucrados en la especificacion del sistema, en la definicion de su arquitectura y en la 
integracion de las diferentes partes para crear el sistema final. Estan menos relacionados con 
la ingenieria de los componentes del sistema (hardware, software, etc.). 

La ingenieria de sistemas es mas antigua que la del software. Por mas de 100 anos, las per- 
sonas han especificado y construido sistemas industriales complejos, como aviones y plantas 
quimicas. Sin embargo, puesto que se ha incrementado el porcentaje de software en los siste- 
mas, las tecnicas de ingenieria del software tales como el modelado de casos de uso y la ges- 
tion de la configuracion se utilizan en el proceso de ingenieria de sistemas. En el Capitulo 2 
se traia con mayor detalle la ingenieria de sistemas. 

1.1.5 iQue es un proceso del software? 

Un proceso del software es un conjunto de actividades y resultados asociados que producen un 
produelo de software. Estas actividades son llevadas a cabo por los ingenieros de software. 
Existen cuatro actividades fundamentales de procesos (incluidas mas adelante en este libro) 
que son comunes para todos los procesos del software. Estas actividades son: 

1. Especificacion de! software donde los clientes e ingenieros definen el software a pro- 
ducir y las restricciones sobre su operacion. 

2. Desarrollo del software donde el software se disefia y programa. 

3. Validation del software donde el software se valida para asegurar que es lo que el 
cliente requiere. 

4. Evolucion del software donde el software se modifica para adaptarlo a los cambios re- 
queridos por el cliente y el mercado. 
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Diferentes tipos de sistemas necesitan diferentes procesos de desarrollo. Por ejemplo, el 
software de tiempo real en un avion tiene que ser completamente especificado antes de que 
empiece el desarrollo, mientras que enun sistema de comercio electronico, la especificacion 
y el programa normalmente son desarrollados juntos. Por lo tanto, estas actividades generi- 
cas pueden organizarse de diferentes formas y describirse en diferentes niveles de detalle para 
diferentes tipos de software. Sin embargo, el uso de un proceso inadecuado del software pue- 
de reducir la calidad o la utilidad del producto de software que se va a desarrollar y/o incre- 
mentar los costes de desarrollo. 

En el Capitulo 4 se tratan con mas detalle los procesos del software, y en el Capitulo 28 
se aborda el tema de la mejora de dicho proceso. 

1.1.6 tQue es un modelo de procesos del software? 

Un modelo de procesos del software es una descripcion simplificada de un proceso del 
software que presenta una vision de ese proceso. Estos modelos pueden incluir actividades 
que son parte de los procesos y productos de software y el papel de las personas involucra- 
das en la ingenieria del software. Algunos ejemplos de estos tipos de modelos que se pueden 
producir son: 

1 . Un modelo de flujo de trabajo. Muestra la secuencia de actividades en el proceso jun- 
to con sus entradas, salidas y dependencias. Las actividades en este modelo represen- 
tan acciones humanas. 

2. Un modelo de flujo de datos o de actividad. Representa el proceso como un conjunto 
de actividades, cada una de las cuales realiza alguna transformacion en los datos. 
Muestra como la entrada en el proceso, tal como una especificacion, se transforma en 
una salida, tal como un disefio. Pueden representar transformaciones llevadas a cabo 
por las personas o por las computadoras. 

3 . Un modelo de rol/accion. Representa los roles de las personas involucrada en el pro- 
ceso del software y las actividades de las que son responsables. 

La mayor parte de los modelos de procesos del software se basan en uno de los tres mo- 
delos generales o paradigmas de desarrollo de software: 

1 . El enfoque en cascada. Considera las actividades anteriores y las representa como fa- 
ses de procesos separados, tales como la especificacion de requerimientos, el disefto 
del software, la implementacion, laspruebas, etcetera. Despues de que cada etapaque- 
da definida «se firma» y el desarrollo continua con la siguiente etapa. 

2. Desarrollo iterativo. Este enfoque entrelaza las actividades de especificacion, 
desarrollo y validacion. Un sistema inicial se desarrolla rapidamente a partir de 
especificaciones muy abstractas. Este se refinabasandose en las peticiones del clien- 
te para producir un sistema que satisfaga las necesidades de dicho cliente. El sistema 
puede entonces ser entregado. De forma alternativa, se puede reimplementar uti- 
lizando un enfoque mas estructurado para producir un sistema mas solido y man- 
ten i ble. 

3 . Ingenieria del software basada en componentes ( CBSE). Esta tecnica supone que las 
partes del sistema existen. El proceso de desarrollo del sistema se enfoca en la inte- 
gracion de estas partes mas que desarrollarlas desde el principio. En el Capitulo 19 se 
estudia la CBSE. 

En losCapitulos4y 17 se trataran nuevamente estos modelos de procesos genericos. 
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1.1.7 tCuales son los costos de la ingeniena del software? 

No existe una respuesta sencilla a esta pregunta ya que la distribucion de costos a traves de las 
diferentes actividades en el proceso del software depende del proceso utilizado y del tipo de 
software que se vaya a desarrollar. Por ejemplo, el software de tiempo real normalmente re- 
quiere una validacion y pruebas mas extensas que los sistemas basados en web. Sin embargo, 
cada uno de los diferentes enfoques genericos al desarrollo del software tiene un perfil de dis- 
tribucion de costos diferente a traves de las actividades del proceso del software. Si se consi- 
dera que el costo total del desarrollo de un sistema de software complejo es de 100 unidades de 
costo, la Figura 12 muestra como se gastan estas en las diferentes actividades del proceso. 

En el enfoque en cascada, los costos de especificacion, disefio, implementacion e integra- 
cion se miden de forma separada. Observe que la integracion y pruebas del sistemas son las 
actividades de desarrollo mas caras. Normalmente, este supone alrededor del 40% del costo 
del desarrollo total, pero para algunos sistemas criticos es probable que sea al menos el 50% 
de los costos de desarrollo del sistema. 

Si el software se desarrolla utilizando un enfoque iterativo, no existe division entre la es- 
pecificacion, el disefio y el desarrollo. En este enfoque, los costos de la especificacion se re- 
ducen debido a que solo se produce la especificacion de alto nivel antes que el desarrollo. La 
especificacion, el disefio, la implementacion, la integracion y las pruebas se llevan a cabo en 
paralelo dentro de una actividad de desarrollo. Sin embargo, aun se necesita una actividad in- 
dependiente de pruebas del sistema una vez que la implementacion inicial este completa. 

La ingenieria del software basada en componentes solo ha sido ampliamente utilizada 
durante un corto periodo de tiempo. En este enfoque, no tenemos figuras exactas para los 
costos de las diferentes actividades del desarrollo de software. Sin embargo, sabemos que los 
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costos de desarrollo se reducen en relacion a los costos de integracion y pruebas. Los costos 
de integracion y pruebas se incrementan porque tenemos que asegurarnos de que los compo- 
nentes que utilizamos cumplen realmente su especificacion y funcionan como se espera con 
otros componentes. 

Ademas de los costos de desarrollo, existen costos asociados a cambios que se le hacen al 
software unavezque esta enuso. Los costos de evolucion variandrasticamente dependiendo 
del tipo de sistema. Para sistemas software de larga vida, tales como sistemas de orden y de 
control que pueden ser usados durante 10 anos o mas, estos costos exceden a los de desarro- 
llo por un factor de 3 o 4, como se muestra en la barra inferior en la Figura 1.3. Sin embargo, 
los sistemas de negocio mas pequenos tienen una vida mucho mas corta y, correspondiente- 
mente, costos de evolucion mas reducidos. 

Esta distribucion de costos se cumple para el software personalizado, el cual es especifi- 
cado por un cliente y desarrollado por un contratista. Para productos de software que se ven- 
den (mayormente) para PCs, el perfil del costo es diferente. Estos productos comunmente se 
desarrollan a partir de una especificacion inicial utilizando un enfoque de desarrollo evoluti- 
vo. Los costos de la especificacion son relativamente bajos. Sin embargo, debido que se pre- 
tende utilizarlos en diferentes configuraciones, deben ser probados a fondo. La Figura 1.3 
muestra el perfil del costo que se puede esperar para estos producios. 

Los costos de evolucion para productos de software genericos son dificiles de estimar. En 
muchos casos, existe poca evolucion de unproducto. Unavezque una version deproducto se 
entrega, se inicia el trabajo para entregar la siguiente y, por razones de mercadotecnia, esta se 
presenta como un producto nuevo (pero compatible) mas que como una version modificada 
de un producto que el usuario ya adquirio. Por lo tanto, los costos de evolucion no se consi- 
deran de forma separada como en el caso del software personalizado, sino que son sencilla- 
mente los costos del desarrollo para la siguiente version del sistema. 

1.1.8 iQue son los metodos de la Ingenlena del software? 

Un metodo de ingenieria del software es un enfoque estructurado para el desarrollo de 
software cuyo proposito es facilitar laproduccion de software de altacalidad de una forma 
costeable. Metodos como Analisis Estructurado (DeMarco, 1978) y JSD (Jackson, 1983) 
fueron los primeros desarrollados en los anos 70. Estos metodos intentaron identificar 
los componentes funcionales basicos de un sistema, de tal forma que los metodos orien- 
tados a funciones aun se utilizan ampliamente. En los anos 80 y 90, estos metodos orienia- 
dos a funciones fueron complementados por metodos orientados a objetos, como los 
propuestos por Booch (1994) y Rumbaugh (Rumbaugh et al., 1991). Estos diferentes 
enfoques se han integrado en un solo enfoque unificado basado en el Lenguaje de Mode- 
lado Unificado (UML) (Booch et al., 1999; Rumbaugh et aL, 1999a; Rumbaugh et 
al., 1999b). 

No existe un metodo ideal, y metodos diferentes tienen distintas areas donde son aplica- 
bles. Por ejemplo, los metodos orientados a objetos a menudo son apropiados para sistemas 
interactivos, pero no para sistemas con requerimientos rigurosos de tiempo real. 
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Todos los metodos se basan en la idea de modelos graficos de desarrollo de un sistema y 
en el uso de estos modelos como un sistema de especificacion o diseno. Los metodos inclu- 
yen varios componentes diferentes (Figura 1.4). 

1.1.9 < .0ue es CASE? 

CASE (Ingenieria del Software Asistida por Computadora) comprende un amplio abanico de 
diferentes tipos de programas que se utilizan para ayudar a las actividades del proceso del soft- 
ware, como el analisis de requerimientos, el modelado de sistemas, la depuracion y las prue- 
bas. En la actualidad, todos los metodos vienen con tecnologia CASE asociada, como los edi- 
torespara las notacionesutilizadas en el metodo, modulo sde analisis que verifican el modelo 
del sistema segun las reglas del metodo y generadores de informes que ayudan a crear la do- 
cumentacion del sistema. Las herramientas CASE tambien incluyen un generador de codigo 
que automaticamente genera codigo fuente a partir del modelo del sistema y de algunas guias 
de procesos para los ingenieros de software. 

1.1.10 iCuales son los atributos de un buen software? 

Asi como los servicios queproveen, los productos de software tienen uncierto numero de atri- 
butos asociados que reflejan la calidad de ese software. Estos atributos no estan directamen- 
te asociados con lo que el software hace. Mas bien, reflejan su comportamiento durante su eje- 
cucion y en la estructura y organizacion del programa fuente y en la documentacion asociada. 
Ejemplos de estos atributos (algunas veces llamados atributos no funcionales) son el tiempo 
de respuesta del software a una pregunta del usuario y la comprension del programa fuente. 

El conjunto especifico de atributos que se espera de un sistema de software depende ob- 
viamente de su aplicacion. Por lo tanto, un sistema bancario debe ser seguro, un juego inter- 
active debe tener capacidad de respuesta, un interrupter de un sistema telefonico debe ser Fia- 
ble, etcetera. Esto se generaliza en el conjunto de atributos que se muestra en la Figura 1 .5, el 
cual tiene las caracteristicas esenciales de un sistema de software bien disefiado, 





Descripciones de! modelo de) sistema 


Descripciones de los modelos del siste- 
ma que desarrollara y la notacton utiliza- 
da para definir estos modetos. 


Modelos de objetos, de ftujo de dates, 
de maquina de estado, etcetera. 


Reglas 


Restricdones que siempre aptican a los 
modelos de sistemas. 


Cada entidad de un modelo de sistema 
debe tener un nombre unico. 


Recomendaciones 


Heurfstica que caracteriza una buena 
practica de dtsefto en este metodo. Se- 
guir estas recomendaciones debe dar 
como resurtado un modelo del sistema 
Wen organizado. 


Ningun objeto debe tener mas de siete 
subobjetos asociados a 61. 


Gufas en el proceso 


Descripciones de las actividades que de- 
ben seguirse para desarrollar los mode- 
los del sistema y la organizacion de estas 
actividades. 


Los atributos de los objetos deben docu- 
mentarse antes de definir las operacio- 
nes asociadas a un objeto. 



Figura 1.4 Componentes del metodo. 
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Mantenibilktad 


El software debe escribirse de tal forma que pueda evokidonar pan cumpfif las necesida- 
des decambio de los dierrtes. Este es un atributo aftico debidoa que el cambio en d soft- 
ware es una consecuenda inevitable de un cambio en d entomo de negodos. 


Confiabilidad 


La confiabilidad dd software tiene un gran numero de caraderisticas, induyendo la fiabilV 
dad, protecddn y seguiidad. El software confiable no debe causar daftos ftekos o ecorr6rru- 
cos en d caso de una fafla dd sstema. 


Eficiencia 


El software no debe hacer que se matgasten los recuisos dd sistema, como la memoria y los 
ridos de procesamiento. Por lo tanto, la efidenda induyetiempos de respuesta y de proce- 
sarniento, utilization de la memoria, etcetera. 


UsabHidad 


El software debe ser ftdl de utiizar, sin esfueizo adidanal, por d usuario para quien est* dt- 
serlado. Esto signifies que debe tener una interfaz de usuario apropiada y una documenta- 
donadecuada. 



Figura 1 .5 Atributos esenciales de un buen software. 



1.1.11 iCuales son los retos fundamentales que afronta la Ingenieria 
del software? 

En el siglo xxi, la ingenieria del software afronta tres retos fundamentales: 

1. El reto de la heterogeneidad. Cada vez mas, se requiere que los sistemas operen como 
sistemas distribuidos en redes que incluyen diferentes tipos de computadoras y con 
diferentes clases de sistemas de soporte. A menudo es necesario integrar software nue- 
vo con sistemas heredados mas viejos escritos en diferentes lenguajes de programa- 
cion. El reto de la heterogeneidad es desarrollar tecnicas para construir software con- 
fiable que sea lo suficientemente flexible para adecuarse a esta heterogeneidad. 

2. El reto de la entrega. Muchas tecnicas tradicionales de ingenieria del software consu- 
men tiempo. El tiempo que estas consumen es para producir un software de calidad. 
Sin embargo, los negocios de hoy en dia deben tener una gran capacidad de respues- 
ta y cambiar con mucha rapidez. Su software de soporte tambien debe cambiar con la 
misma rapidez. El reto de la entrega es reducir los tiempos de entrega para sistemas 
grandes y complejos sin comprometer la calidad del sistema. 

3. El reto de la conflanza. Puesto que el software tiene relacion con todos los aspectos 
de nuestra vida, es esencial que podamos confiar en el. Esto es especialmente impor- 
tante en sistemas remotos de software a los que se accede a traves de paginas web o 
de interfaces de servicios web, El reto de la confianza es desarrollar tecnicas que de- 
muestren que los usuarios pueden confiar en el software. 

Por supuesto, estos no son independientes. Por ejemplo, es necesario hacer cambios ra- 
pidos a los sistemas heredados para proveerlos de una interfaz de servicio web. Para tratar es- 
tos retos, necesitaremos nuevas herramientas y tecnicas, asi como formas innovadoras de com- 
binacion y uso de metodos de ingenieria del software existentes. 

1.2 Responsabilidad profesional y etica 



Como otras disciplinas de la ingenieria, la ingenieria del software se lleva a cabo dentro de 
un marco legal y social que limita la libertad de los ingenieros. Los ingenieros de software 



1.2 • Responsabilidad profesional y etica 



13 



deben aceptar que su trabajo comprende responsabilidades mas amplias que simplemente la 
aplicacion de habilidades tecnicas. Deben comportarse de una forma etica y moral responsa- 
ble si es que desean ser respetados como profesionales. 

No basta con decir que usted siempre debe poseer estandares normales de honestidad e 
integridad. No deberia utilizar su capacidad y sus habilidades para comportarse de forma 
deshonesta o de forma que deshonre la profesion de la ingenieria del software. Sin em- 
bargo, existen areas donde los estandares de comportamiento aceptable no estan acotados 
por las leyes, sino por la mas tenue nocion de responsabilidad profesional. Algunas de es- 
tas son: 

1. Confidencialidad. Usted normalmente debe respetar la confidencialidad de sus em- 
pleadores o clientes independientemente de que se haya firmado un acuerdo formal de 
confidencialidad. 

2. Competencia. No debe falsificar su nivel de competencia, ni aceptar conscientemente 
trabajos que estan fuera de su capacidad. 

3 . Derechos de propiedad intelectual. Debe ser consciente de las leyes locales que go- 
biernan el uso de la propiedad intelectual, como las patentes y el copyright. Debe 
asegurarse de que la propiedad intelectual de los empleadores y clientes esta prote- 
gida. 

4. Uso Inaproplado de ios computadoras. No debe emplear sus habilidades tecnicas 
para utilizar de forma inapropiada las computadoras de otras personas. El uso ina- 
propiado de las computadoras va desde los relativamente triviales (utilizar juegos 
en la maquina de un empleado, por ejemplo) hasta los extremadamente serios (di- 
fusion de virus). 

Las sociedades e instituciones profesionales tiene que desempenar un papel importante 
en el establecimiento de estandares eticos. Organizaciones como la AC M , elIEEE(Instituto 
de Ingenieros Electricosy Electr6nicos)y la British Computer Society publican un codigo de 
conducta profesional o de etica. Los miembros de estas organizaciones se comprometen a 
cumplir ese codigo cuando se inscriben en ellas. Estos codigos de conducta generalmente se 
refieren al comportamiento etico fundamental. 

La A C M y el IEEE han cooperado para crear un codigo de etica y practica profesional. 
Este codigo existe en forma reducida, como se muestra en la Figura 1.6, y en forma extendi- 
da (Golterbam et ai, 1999), la cual agrega detalle y sustancia a la version reducida. El fun- 
damento sobre el que se asienta este codigo se resume en los dos primeros parrafos de la ver- 
sion extendida: 

Las computadoras tienen un papel central y creciente en el comercio, la industria, el 
gobierno, la medicina, la education, el entretenimiento y la socledad en general. Los 
ingenieros de software son aquellos que contribuyen con su participation directa o por 
su ensehanza, al andlisis, especificacion, diseho, desarrollo, certification, manteni- 
ntiento y pruebas de los sistentas de software. Debido a \uspapeles en el desarrollo de 
sistentas de software, los ingenieros de software tienen significativas oportunidades de 
hacer elbien o causar daho,permitir que otros hagan elbien o causen daho, o influir 
en otros para hacer el bien o causar daito. Para asegurar, tanto como sea posible, que 
sus esfuerzos serdn utilizados para bien, los ingenieros de software deben comprome- 
terse consigo mismos para hacer de la ingenieria del so/ware una profesion de bene- 
ficioy respeto. De acuerdo con este compromiso, los ingenieros de software deben cum- 
plir el siguiente Codigo de Etica y Practica Profesional. 
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Codigo da Etica y Practica Profeslonal de la Irtfcnleria dd Software 

ACM/IEEE-CS Fuerza de Tarea Conjunta sobre Etica y Practica Profesional en la Ingeniena del Software 
PREAMBULO 

La version corta del codigo resume las aspiraciones en un alto nivel de abstraction. Las clausulas que se incluyen en la ver- 
sion completa proporcionan ejemplos y detalles de como estas aspiraciones cambian la forma en que actuamos como pro- 
fesionales de la ingeniena del software. Sin las aspiraciones, los detalles pueden llegar a ser solo terminos juridicos tediosos; 
sin los detalles, las aspiraciones pueden llegar a ser altisonantes pero vadas; juntas, las aspiraciones y los detalles forman un 
codigo cohesivo. 

Los ingenierosde software deben comprometerse consigo mismos para hacerdel analisis, la especificacion, el diseno, el des- 
arrollo, las pruebasy el mantenimiento del software una profesion beneficiosa y respetada. En concordancia con su compro- 
mise! con la salud, ta seguridad y el bienestar del publico, los ingenieros de software deben adherirse a los siguientes ocho 
principios: 

1. PUBLICO - Los ingenieros de software deberan actuar en consonancia con el interes publico. 

2. CUENTEY EMPLEADOR— Los ingenieros de software deberan actuar de forma que respondan a los intereses de sus dien- 
tesy empleadores siendo consecuentes con el interes publico. 

3. PRODUCTO - Los ingenieros de software deberan asegurar que sus productos y las rnodrtkadones asociadas cumplan 
los mas altos estandares profesionales posibles. 

4. JUICIO - Los ingenieros de software deberan mantener la integridad e independencia en sus juidos profesionales. 

5. GESTION - Los gerentesy lideres ingenieros de software deberan suscribiry prornodonar un enfoque etico en la gestion 
del desarrollo y mantenimiento dd software. 

6. PROFESION - Los ingenierosde software deberan mantener la integridad yreputacion de la profesion de acuerdo con d 
interes publica 

7. COLEGAS - Los ingenieros de software deberan ser imparciales y apoyar a sus colegas. 

8. PERSONAL - Durante toda sus existenaa, los ingenieros de software deberan aprender lo concerniente a la practica de 
su profesion y prornodonar un enfoque etico en la practica de su profesion. 



Figura 1.6 Codigo de Etica de la ACM/IEEE (€ IEEE/ACM 1999). 



El codigo conticne ocho principios relacionados con el comportamientoy con ;as 
decisiones hechas por ingenieros de software profesionales, incluyendo practican- 
tes, educadores, administradores, supervisoresy creadores de politicas, asi'como 
aprendices y estudiantes de la profesion. Los principios identifican las relaciones eti- 
cas en las que ;os individuos, gruposy organizaciones participan, y las obligacio- 
nes primarias dentro de estas relaciones. Las clausulas de cada principio son ilus- 
traciones de algunas de las obligaciones incluidas en estas relaciones. Estas 
ohligaciones sefundamentan en la humanidad del ingeniero de software, con espe- 
cial c it i da do en la gente afectada por el trabajo de los ingenieros de software, y los 
elementos unicos de la practica de la ingeniena del software. El codigo prescribe es- 
tas como obligaciones de cualquiera que se I I nine o que aspire a ser un ingeniero de 
software. 

En cualquier situacion en la que diferentes personas tienen distintos puntos de vista y ob- 
jetivos, es posible encontrar problemas eticos. Por ejemplo, si usted esta en desacuerdo, en 
principio, con las politicas de un directivo de categoria superior en la compania, jcomo de- 
beria reaccionar? Desde luego, esto depende de cada individuo y de la naturaleza de la dis- 
cordancia. ^Es mejor argumentar a favor de su posicion dentro de la organizacion o renun- 
ciar de acuerdo con sus principios? Si piensa que existen problemas con un proyecto de 
software, ^cuando se deben comunicar estos al gerente? SI estos se discuten cuando son solo 
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una sospecha, puede ser una sobre reaccion a la situacion, si lo deja para mas tarde, puede 
ser imposible resolver las dificultades. 

Tales problemas eticos aparecen en nuestra vida profesional y, afortunadamente, en mu- 
chos casos son relativamente menores o se pueden resolver sin mucha dificultad. Cuando no 
se puedan resolver, los ingenieros se enfrentaran, quizas, con otro problema. La accion con 
base en sus principios podria ser renunciar a su trabajo, pero esto puede afectar a otros, por 
ejemplo, a sus colaboradores o sus hijos. 

Una situacion particularmente dificil para los ingenieros profesionales surge cuando su 
empleador actua de una forma no etica. Por ejemplo, una compania es responsable de des- 
arrollarun sistema critico de seguridad y, debido a las presiones de tiempo, falsifica la va- 
lidacion de proteccion de los registros. ^Es responsabilidad del ingeniero mantener la con- 
fidencialidad o alertar al cliente o hacer publico, de alguna forma, que el sistema entregado 
es inseguro? 

El problema aqui es que no existen absolutos cuando se trata de proteccion. Aun cuando 
el sistema no haya sido validado de acuerdo con los criterios predefinidos, estos pueden ser 
demasiado estrictos. El sistema puede, de hecho, operar de forma segura a traves de su tiem- 
po de vida. Pero puede darse el caso de que, aun cuando sea validado apropiadamente, el sis- 
tema falle y cause un accidente. El descubrimiento temprano de problemas puede resultar per- 
judicial para el empleador y otros empleados; la falta de descubrimiento de problemas puede 
resultar perjudicial para otros. 

Debe tomar su propia decision en estos temas. La posicion etica apropiada depende en- 
teramente del punto de vista de los individuos que estan involucrados. En este caso, el po- 
tencial para el dano, el grado del dafio y la gente afectada por el deben influir en la deci- 
sion. Si la situacion es muy peligrosa, sejustifica su publicacion en la prensa nacional (por 
ejemplo). Sin embargo, se debe tratar de resolver la situacion respetando los derechos del 
empleador. 

Otra cuestion etica es la participacion en el desarrollo de sistemas militares y nucleares. 
Algunas personas tienen una opinion firme sobre estos temas y no desean participar en nin- 
gun desarrollo de sistemas asociados con sistemas militares. Otros trabajaran en sistemas mi- 
litares, pero no en sistemas de armamento. Algunos otros sentiran que la defensa de la nacion 
es un principio fundamental y no tienen objeciones eticas para trabajar en sistemas de arma- 
mento. 

En esta situacion, es importante que tanto empleadores como empleados se hagan saber 
con anticipacion sus puntos de vista. Cuando una organizacion esta relacionada con el traba- 
jo militar o nuclear, le debe ser posible especificar si los empleados pueden aceptar cualquier 
tarea. De igual forma, si un empleado hace patente que no desea trabajar en tales sistemas, los 
empleadores no deben presionarlo posteriormente. 

El area de etica y responsabilidad profesional ha recibido creciente atencion en los pasa- 
dos anos. Los principios de etica se pueden considerar desde un punto de vista filosofico, y la 
etica de la ingenieriadel software se debe tratar con referencia a estos principios basicos. Este 
es el enfoque considerado por Laudon (Laudon, 1995) y, de forma menos extensa, por Huff 
y Martin (Huffy Martin, 1995). 

Sin embargo, este enfoque me resulta abstracto y dificil de relacionar con mi experiencia 
diaria. Prefiero un enfoque mas concreto comprendido en codigos de conducta y practica. 
Creo que la etica se analiza mejor en un contexto de ingenieria del software y no como un 
tema por si solo. En este libro, por lo tanto, no incluire consideraciones eticas abstractas sino 
que, donde sea apropiado, incluire ejemplos en los ejercicios que puedan servirde punto de 
partida para una discusion etica. 
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PUNTOS CLAVE 

• La Ingenlerfa del software es una disci pi ina de Ingenieria que comprende todos los aspectos de la produce ion 
de software. 

• Los productos de software consisten en programas desarrollados y en la documentacion asociada. Los atri- 
butos esenciales de los productos son la mantenibilidad, con Habilidad, eficiencia y aceptabilidad. 

• El proceso del software incluye todas las actividades relativas al desarrollo del software. Las actividades de 
alto niveldeespecificacion del software, el desarrollo, (avalidaci6ny(aevolucionsonpartedetodos tos pro- 
cesos software. 

• Los metodos son formas organizadas de producir software. Incluyen sugerencias para el proceso que se debe 
seguir, la notacion que se va a utilizar, los modelos del sistema que hay que desarrollary las reglas que go- 
biernan estos modelos y las pautas de diseho. 

• Las herramientas CASE son sistemas de software que estan disehados para ayudar a las actividades rutina- 
rias del proceso del software, como editar diagramas de diseno, verificar ta consistencia de estos y mantener 
un banco de pruebas de los programas ejecutados. 

• Los ingenieros de software tienen responsabilidades en la prof es ton de la Ingenlerfa y en la sociedad. No solo 
deben estar pendientes de los aspectos tecnicos. 

• Las sociedades profesionales publican eddigos de conducta que definen los estandares de comportamiento 
esperado por sus miembros. 



Fundamentals of Software Engineering. Un texto general sobre la ingenieria del software que da una perspectiva de 
la materia bastante diferente de la que da este libro. (C. Ghezi et ai, Prentice Hall, 2003.) 

«Software engineering: The state of the practices Un numero especial del IEEE Software que incluye varios articu- 
los que estudian la practica actual en la ingenieria del software, como ha cambiado y el grado en el cual se utilizan 
nuevas tecnologias del software. [IEEE Software, 20 (6), noviembre de 2003.] 

Software Engineering: An Engineering Approach. Un texto general que toma un enfoque bastante diferente del de 
mi libro pero que incluye algunos casos de estudio utiles. 0. F. Peters yW. Pedrycz, 2000, John Wiley & Sons.) 

Professional issues in Software Engineering. Este es un excelente libro que analiza los aspectos legales, profesio- 
nales y eticos. Yo prefiero su enfoque practico a los textos mas teoricos sobre etica. (F. Bott et al., 3.2 edicion, 2000, 
Taylor & Francis.) 

«Software Engineering Code of Ethics is approved». Un articulo que estudia las bases del desarrollo del Codigo de 
Etica de la ACM/IEEE e incluye tanto la version reducida como la version extendida del codigo. {Comm. ACM, D. Got- 
terbarn etai, octubre de 1999.) 

«No silver bullet: Essence and accidents of software engineering'). Pese al tiempo transcurrido desde su publicacion, 
este articulo es una buena introduccion general a los problemas de la ingenieria del software. El mensaje esencial 
del articulo, que no hay una sola respuesta a los problemas de la ingenieria del software, no ha cambiado. [F. P. Bro- 
oks, IEEE Computer, 20(4), abril de 1987.] 
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EJERCICIOS 



11 Haciendo referencia a la distribucion de costos del software inidicados en la Seccion 1.1.6, explique por que 
es apropiado considerar que el software es mas que programas que son ejecutados por los usuarios finales 
de un sistema. 

12 ^Cuales son las diferencias entre el desarrollo de un producto de software generico y el desarrollo de un soft- 
ware personalizado? 

13 ^Cuales son los cuatro atributos importantes que todos los productos de software deben tener? Sugiera 
otros cuatro atributos que pueden ser significativos. 

14 ^.Cual es la diferencia entre un modelo del proceso del software y un proceso del software? Sugiera dos for- 
mas en las que un modelo del proceso del software ayuda en la identificacion de posibles mejoras del pro- 
ceso. 

15 Explique por que los costos de pruebas de software son particularmente altos para productos de software 
genericos que se venden a un mercado amplio. 

Los metodos de la ingenieria del software se empezaron autilizarcuando la tecnologiaCASE estuvo dispo- 
nible para apoyarlos. Mencione cinco tipos de metodos de ayuda que proporcionen las herramientas CASE. 

17 Ademas de los retos de la heterogeneidad, la rapida entrega y la confianza, identifique otros problemas y 
retos que la ingenieria del software afrontara en el siglo xxi. 

Comente si los ingenieros profesionales deben atestiguar de la misma forma que los doctores o los aboga- 
dos. 

19 Para cada una de las clausulas del Codigo de Etica de la ACM/IEEE que se muestra en la Figura 1.6, sugiera 
un ejemplo apropiado que ilustre esa clausula. 

LID Para contrarrestar al terrorismo, muchos paises estan planeando el desarrollo de sistemas informaticos que 
sigan la pista de un gran numero de sus ciudadanos y de sus acciones. Desde luego, esto tiene implicacio- 
nes sobre la privacidad. Comente la etica de desarrollar este tipo de sistema. 



2 A 

Sistemas 
socio-tecnicos 

Objetivos 

Los objetivos de este capitulo son introducir el concepto de un 
sistema socio-tecnico — que incluye personas, software y 
hardware — y el proceso de la ingenieria de sistemas. Cuando haya 
leido este capitulo: 

• sabra que se entiende por sistema socio-tecnico y 
comprendera la diferencia entre un sistema tecnico 
informatico y un sistema socio-tecnico; 

• conocera el concepto de propiedades emergentes de los 
sistemas, como la habilidad, el rendimiento, la seguridad y la 
proteccion; 

• entendera las actividades implicadas en el proceso de la 
ingenieria de sistemas; 

• entendera por que el contexto organizacional de un sistema 
afecta a su diseno y uso; 

• sabra que significa «sistema heredado», y por que estos 
sistemas son a menudo criticos para tas operaciones de 
muchos negocios. 



Contenidos 

2.1 Propiedades emergentes de los sistemas 

2.2 Ingenieria de sistemas 

2 . 3 Organizaciones, personas y sistemas informaticos 

2.4 Sistemas heredados 
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El termino sistema es umversalmente usado. Hablamos sobre sistemas informaticos, sistemas 
operativos, sistemas de pago, el sistema educacional, el sistema de gobierno, etcetera. Estos 
son obviamente usos bastante diferentes de la palabra sistema aunque coinciden en que, de 
algun modo, el sistema es mas que simplemente la suma de sus partes. 

Sistemas muy abstractos tales como el sistema de gobierno estan fuera del ambito de este 
libro. Consecuentemente, me centro aqui en sistemas que incluyen computadoras y que tie- 
nen algun proposito especifico, como permitir la comunicacion, ayudar a la navegacion y cal- 
cular salarios. Por lo tanto, una definicion util de estos tipos de sistemas es la siguiente: 

Un sistema es una coleccion de componentes Inter relacionados que trabajan conjun- 
tamente para cumplir algun objetivo. 

Esta definicion general comprende una amplia serie de sistemas. Por ejemplo, un sistema 
tan simple como un boligrafo incluye tres o cuatro componentes hardware. En contraste, un 
sistema de control del trafico aereo incluye miles de componentes hardware y software ade- 
mas de los usuarios humanos que toman decisiones basadas en la informacion del sistema. 

Los sistemas que incluyen software se dividen en dos categorias: 

• Sistemas tecnicos informaticos: son sistemas que incluyen componentes hardware y soft- 
ware, pero no procedimientos y procesos. Ejemplos de sistemas tecnicos son las televi- 
siones, los telefonos moviles y la mayoria del software de las computadoras personales. 
Los individuos y organizaciones usan sistemas tecnicos para algun fin, pero el conoci- 
miento de este fin no es parte del sistema. Por ejemplo, el procesador de textos que estoy 
utilizando no es consciente de que se estautilizando para escribirun libro. 

• Sistemas socio-tecnicos: comprenden uno o mas sistemas tecnicos pero, crucialmeme, 
tambien incluyen conocimiento de como debe usarse el sistema para alcanzar algun ob- 
jetivo mas amplio. Esto quiere decir que estos sistemas han definido los procesos opera- 
tivos, incluyen personas (los operadores) como partes inherentes del sistema, son gober- 
nados porpoliticas y reglas organizacionales y pueden verse afectados porrestricciones 
externas tales como leyes nacionales y politicas reguladoras. Por ejemplo, este libro fue 
creado porun sistema socio-tecnico de la industria editorial que incluye varios procesos 
y sistemas tecnicos. 

Las caracteristicas esenciales de los sistemas socio-tecnicos son las siguientes: 

1. Tienen propiedades emergentes que son propiedades del sistema como un todo mas 
que asociadas con partes individuals del sistema. Las propiedades emergentes de- 
penden tanto de los componentes del sistema como de las relaciones entre ellos. Como 
esto es tan complejo, las propiedades emergentes solo pueden ser evaluadas una vez 
que el sistema ha sido montado. 

2. Son a menudo no deterministas. Esto significa que, cuando se presentan con una en- 
trada especifica, no siempre producen la misma salida. El comportamiento del siste- 
ma depende de operadores humanos, y las personas no siempre reaccionan de la mis- 
ma forma. Ademas, el uso del sistema puede crear nuevas relaciones entre los 
componentes del sistema y, por lo tanto, cambiar su comportamiento emergente. 

3. El grado en que el sistema apoya los objetivos organizacionales no solo depende del 
sistema en si mismo. Tambien depende de la estabilidad de estos objetivos, de las re- 
laciones y conflictos entre los objetivos organizacionales y de como las personas en la 
organizacion interpretan estos objetivos. Una nueva direccion puede reinterpretar los 
objetivos organizacionales para los que un sistema esta disenado, y un sistema «exi- 
toso» puede convertirse en un «fracaso». 
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En este libro, se estudian los sistemas socio-tecnicos que incluyen hardware y software, los 
cuales han definido procesos operativos y ofrecen una interfaz, implementada en software, a 
los usuarios humanos. Los ingenieros de software deben poseerun conocimiento de los siste- 
mas socio-tecnicos y la ingenieria de sistemas (White etai., 1993; Thayer, 2002) debido a la 
importancia del software en estos sistemas. Por ejemplo, hubo menos de 10 megabytes de soft- 
ware en el programa espacial Apolo que puso un hombre en la Luna en 1 969, pero existen mas 
de 100 megabytes de software en los sistemas de control de la estacion espacial Columbus. 

Una caracteristica de los sistemas es que las propiedades y el comportamiento de los com- 
ponentes del sistema estan inseparablemente entremezclados. El funcionamiento exitoso de 
cada componente del sistema depende del funcionamiento de otros componentes. Asi, el soft- 
ware solo puede funcionar si el procesador es operativo. El procesador solo puede hacer cal- 
culos si el sistema de software que define las operaciones se ha instalado de forma acertada. 

Por lo general, los sistemas son jerarquicos y de este modo incluyen otros sistemas. Por 
ejemplo, un sistema de ordenes y control policiaco puede incluirun sistema de informacion 
geografica para proporcionar los detalles de la localizacion de incidentes. Estos sistemas se 
denominan subsistetnas. Una caracteristica de estos es que pueden operarpor si solos como 
sistemas independientes. Por lo tanto, el mismo sistema de informacion geografica se puede 
utilizar en diferentes sistemas. 

Puesto que el software es intrinsecamente flexible, los ingenieros de software deben resol- 
ver muchos problemas inesperados. Por ejemplo, digamos que la instalacion de un radar se ha 
situado de tal forma que aparece una imagen fantasma de la imagen del radar. No es practico 
mover el radar a un sitio con menos interferencias, por lo que los ingenieros de software tienen 
que encontrar otra tecnica para eliminar estas imagenes fantasma. Su solucion podria ser me- 
jorar las capacidades del procesamiento de imagenes del software para eliminar las imagenes 
fantasma. Esto puede ralentizar el software de tal forma que el rendimiento sea inaceptable. El 
problema se puede entonces caracterizar como un «fallo de funcionamiento del software)), 
mientras que, en realidad, fue un fallo en el proceso de diseno del sistema en su totalidad. 

Esta situacion, en que a los ingenieros de software se les deja el problema de mejorar las 
capacidades del software sin incrementar el costo del hardware, es muy comun. Muchos de 
los llamados fallos de funcionamiento del software no son consecuencia de problemas inhe- 
rentes a este; son el resultado de tratar de cambiarlo para adecuarlo a las modificaciones en 
los requerimientos de la ingenieria de sistemas. Un buen ejemplo de esto es el fallo en el sis- 
tema de equipaje del aeropuerto de Denver (Swartz. 1996). donde se esperaba que el softwa- 
re de control se hiciera cargo de algunas limitaciones del equipo utilizado. 

La ingenieria del software es, por lo tanto, critica para el desarrollo acertado de complejos 
sistemas informaticos socio-tecnicos. Como ingeniero de software, usted no deberiaocupar- 
se solo del software en si mismo, sinoque ademas deberiatenerun conocimiento mas amplio 
de como el software interactua con otros sistemas hardware y software y como se debe usar. 
Este conocimiento le ayuda a entender los limites del software, a disenar un mejor software 
y a participar como miembros iguales de un grupo de ingenieria de sistemas. 

2.1 Propiedades emergentes de los sistemas 

Las complejas relaciones entre los componentes de un sistema indican que el sistema es mas 
que simplemente la suma de sus partes. Este tiene propiedades que son propiedades del sis- 
tema como un todo. Estas propiedades emergentes (Checkland, 1 98 1 ) no se pueden atribuir 
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a ninguna parte especifica del sistema. Mas bien, emergen solo cuando los componentes del 
sistema han sido integrados. Algunas de estas propiedades pueden derivar directamente de las 
propiedades comparables de los subsistemas. Sin embargo, mas a menudo, resultan de com- 
plejas interrelaciones de los subsistemas que no pueden, en la practica, derivarse de las pro- 
piedades de los componentes individuales del sistema. En la Figura 2.1 se muestran ejemplos 
de algunas propiedades emergentes. 

Existen dos tipos de propiedades emergentes: 

1. Las propiedades emergentes funcionales aparecen cuando todas las partes de un sis- 
tema trabajan de forma conjunta para cumplir algun objetivo. Por ejemplo, una bici- 
cleta tiene la propiedad funcional de ser un instrumento de transporte una vez que sus 
componentes se han conjuntado. 

2. Las propiedades emergentes no funcionales se refieren al comportamiento de los sis- 
temas en su entorno operative Ejemplos de propiedades no funcionales son la fiabili- 
dad, el rendimiento, la seguridad y la proteccion. A menudo son factores criticos para 
sistemas informaticos, ya que un fallo minimo en estas propiedades puede hacer in- 
utilizable el sistema. Algunos usuarios puede que no necesiten ciertas funciones del 
sistema, por lo que este puede ser aceptable sin ellas. Sin embargo, un sistema no fia- 
ble o demasiado lento es probablemente rechazado por todos los usuarios. 

Para ilustrar la complejidad de las propiedades emergentes, considere la propiedad de la 
fiabilidad del sistema. La fiabilidad es un concepto complejo que siempre debe estudiarse en 
el nivel del sistema mas que en el de los componentes individuales. Los componentes de un 
sistema son interdependientes, de tal forma que un fallo en uno de ellos se puede propagar a 
traves del sistema y afectar a la operacion de otros componentes. A veces es dificil predecir 
la manera en que las consecuencias de los fallos de los componentes se propagan a traves del 
sistema. Por consiguiente, no se pueden hacer buenas estimaciones de la fiabilidad en con- 
junto del sistema de los datos de fiabilidad de los componentes del sistema. 

Existen tres influencias conexas sobre la fiabilidad de un sistema: 

1. Fiabilidad del hardware. ^Cual es laprobabilidadde que un componente hardware fa- 
lle y cuanto tiempo lleva reparar ese componente? 



Figura 2.1 

Ejemplos 

de propiedades 

emergentes. 





Volumen 


El volumen de un sistema (el espacio total ocupado) varfa dependiendo de 
como esten ordenadosy conectados los montajes de los componentes. 


Fiabilidad 


La fiabilidad del sistema depende de la fiabilidad de los componentes, pero 
interacciones inesperadas pueden causar nuevos tipos de fallos y, por lo tan- 
to, afectar a la fiabilidad del sistema. 


Proteccion 


La proteccion del sistema (su capacidad para resistir ataques) es una pro- 
piedad compleja que no se puede medir fAcilmente. Los ataques pueden ser 
ideados de forma que no fueron predkhos por tos disefladores del sistema 
y asl veneer las proteccion es incorporadas. 


Reparabitidad 


Esta propiedad refleja hasta que punto results facil arreglar un problema con 
el sistema una vez que ha sido descubierto. Depende de la posibilidad de 
diagnostkar el problema, acceder a los componentes que son defectuosos y 
modtftcar o reemplaur estos componentes. 



Usabilidad Esta propiedad refleja cdmo es de facil usar el sistema. Depende de los com- 

ponentes tfrcnicos del sistema. sus operarios y su entomo de operationes. 
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2. Fiabilidad del software. ^Que probabilidad hay de que un componente software pro- 
duzca una salida incorrecta? Los fallos de funcionamiento del software normalmente 
son distintos de los del hardware en el sentido de que el software no se desgasta. Los 
fallos son normalmente transitorios por lo que el sistema puede continuar funcionan- 
do de spues de que se haya producido un resultado incorrecto. 

3 . Fiabilidad del operador. ^Que probabilidad existe de que un operador de un sistema 
cometa un error? 

Estas influencias estan fuertemente relacionadas. Los fallos de hardware pueden generar 
falsas senales fuera del rango de las entradas esperadas por el software. El software puede en- 
tonces comportarse de forma impredecible. Un error del operador es mas probable en condi- 
ciones de tension, como cuando ocurren fallos del sistema, Estos errores del operador pueden 
afectar al hardware, causando mas fallos, y asi sucesivamente. Por lo tanto, el fallo inicial re- 
cuperable puede convertirse rapidamente en un problema serio que requiera una parada com- 
pleta del sistema. 

Al igual que la fiabilidad. otras propiedades emergentes, como el rendimiento o la usabi- 
lidad. son dificiles de valorar, pero se pueden medir despues de que el sistema este en fun- 
cionamiento. Sin embargo, propiedades como la seguridad y la proteccion presentan diversos 
problemas. Aqui, se tiene conexion no solo con un atributo relacionado con el comporta- 
miento total del sistema, sino con el comportamiento que el sistema no deberia mostrar. Un 
sistema seguro es aquel que no permite accesos no autorizados a sus datos, pero es claramente 
imposible predecir todos los posibles modos de acceso y prohibirlos de forma explicita. Por 
lo tanto, solo es posible valorar estas propiedades por defecto. Esto es. solo se puede saber 
que el sistema es inseguro cuando alguien lo viola. 

2.2 I ngeniena de sistemas 

La ingenieriade sistemas es la actividad de especificar, disefiar, implementar, validar, utilizar 
y mantener los sistemas socio-tecnicos. Los ingenieros de sistemas no solo tratan con el soft- 
ware, sino tambien con el hardware y las interacciones del sistema con los usuarios y su en- 
torno. Deben pensar en los servicios que el sistema proporciona, las restricciones sobre las que 
el sistema se debe construir y funcionar y las formas en las que el sistema es usado para cum- 
plir con su proposito. Como se ha tratado, los ingenieros de software necesitan tener conoci- 
mientos de ingenieriade sistemas, porque los problemas de laingenieriadel software soname- 
nudo el resultado de decisiones de la ingenieriade sistemas (Thayer, 1997; Thayer, 2002). 

Las fases del proceso de la ingenieria de sistemas se muestran en la Figura 2.2. Este pro- 
ceso tuvo una influencia significativa en el modelo en «cascada» del proceso del software que 
se estudia en el Capitulo 4. 

Existen diferencias importantes entre el proceso de la ingenieria de sistemas y el proceso 
de desarrollo del software: 

1 . Alcance litnitado para rehacer el trabajo durante el desarrollo de sistemas. Una vez 
que se han tornado decisiones en la ingenieria del sistema, como la posicion de una 
estacion base en un sistema de telefonia movil, cuesta mucho trabajo cambiarlas. Ra- 
ramente es posible rehacer el trabajo en el diseno del sistema para resolver estos pro- 
blemas. Una razon por la que el software ha llegado a ser tan importante en los siste- 
mas es que permite cambios que se hacen durante el desarrollo del sistema, como 
respuesta a nuevos requerimientos. 
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Figura 2.2 
El proceso 
de la ingenieria 
de sistemas. 




2. Implication interdisciplinaria. Muchas disciplinas de la ingenieria se conjuntan en la 
ingenieria de sistemas. Existe una gran discrepancia debido a que diferentes ingenie- 
ros usan diferente terminologia y convenciones. 

La ingenieria de sistemas es una actividad interdisciplinaria que conjunta equipos de perso- 
nas con diferentes bases de conocimiento. Los equipos de ingenieria de sistemas son necesarios 
debido al amplio conocimiento requerido para considerar todas las implicaciones de las deci- 
siones en el disefio del sistema. Como ejemplo de esto, la Figura 2.3 muestra algunas de las dis- 
ciplinas que conforman el equipo de ingenieria de sistemas para un sistema de control del trafi- 
co aereo (CTA) que utilizan radares y otros sensores para determinar la posicion de los aviones. 

Para muchos sistemas existen posibilidades casi infinitas de equilibrio entre los diferentes 
tipos de subsistemas. Las diferentes disciplinas negocian para decidir que funcionalidad debe 
proporcionarse. A menudo no existe una decision «correcta» sobre como se debe descompo- 
ner un sistema. Mas bien, puede tener varias opciones, pero es posible que no pueda elegir la 
mejor solucion tecnica. Por ejemplo, una alternativa en un sistema de control del trafico ae- 
reo es construir nuevos radares, mas que arreglar las instalaciones existentes. Si los ingenie- 
ros civiles relacionados con este proceso no tienen mas trabajo que hacer, estaran a favor de 
esta opcion debido a que les permite conservar sus trabajos. Pueden justificar esta eleccion 
utilizando argumentos tecnicos. 

2.2.1 Delinicitin de requerimientos del sistema 

Las definiciones de requerimientos del sistema especifican que es lo que el sistema debe hacer 
(sus funciones) y sus propiedades esenciales y deseables. Como en el anal i sis de requerimien- 
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tos del software (tratado en la Parte 2), crear definiciones de requerimientos del sistema re- 
quiere consultarcon los clientes del sistema y con los usuarios finales. Esta fase de definicion 
de requerimientos usualmente se concentra en la derivacion de tres tipos de requerimientos: 

1. Requerimientos funcionales abstractos. Las funciones basicas que el sistema debe pro- 
porcionar se definen en un nivel abstracto. Una especificacion mas detallada de re- 
querimientos funcionales tiene lugaren el nivel de subsistemas. Por ejemplo, en un sis- 
tema de control del trafico aereo, un requerimiento funcional abstracto especificaria 
que una base de datos del plan de vuelo debe usarse para almacenar los planes de vue- 
lo de todos los aviones que entran al espacio aereo controlado. Sin embargo, normal- 
mente no se especificarian los detalles de la base de datos a menos que afecten a los 
requerimientos de otros subsistemas. 

2. Propiedades del sistema. Como se sefialo anteriormente, estas sonpropiedades emer- 
gentes no funcionales del sistema, tales como la disponibilidad, el rendimiento y la se- 
guridad. Estas propiedades no funcionales del sistema afectan a los requerimientos de 
todos los subsistemas. 

3 . Caracteristicas que no debe mostrar el sistema. Algunas veces es tan importante es- 
pecificar lo que el sistema no debe hacercomo especificar lo que debe hacer. Por ejem- 
plo, si esta especificando un sistema de control del trafico aereo, puede especificar que 
el sistema no debe presentar demasiada informacion al controlador. 

Una parte importante de la fase de definicion de requerimientos es establecer un conjunto 
completo de objetivos que el sistema debe cumplir. Estos no necesariamente deben expresar- 
se forzosamente en terminos de la funcionalidad del sistema, pero deben definir por que se 
construye el sistema para un entorno particular. 

Para ilustrar que quiere decir esto, digamos que esta especificando un sistema contra in- 
cendios y deteccion de intrusos para un edificio de oficinas. Un enunciado de los objetivos 
basado en la funcionalidad del sistema seria: 

Construir un sistema de alarma contra incendios e intrusos para el edificio que pro- 
porcione avisos de fuego y de intrusiones no autorizadas tanto internas como externas. 

Este objetivo establece explicitamente que debe serun sistema de alarma que proporcione 
avisos sobre eventos no deseados. Tal enunciado seria apropiado si estuvieramos reempla- 
zando un sistema de alarma existente. En contraste, un enunciado mas amplio de los objeti- 
vos seria: 

Asegurar que el funcionamiento norma! de ;os trabajos realizados en el edificio nose 
interrumpa por eventos como el fuego e intrusion no autorizada. 

Si enuncia el objetivo de esta forma, ampliay limita algunas decisiones en el diseno. Por 
ejemplo, este objetivo permite la proteccion contra intrusos utilizando tecnologiasofisticada, 
sin alarma interna alguna. Tambien puede excluir la utilizacion de extintores para la protec- 
cion del fuego porque puede afectar a los sistemas electricos en el edificio e interrumpir se- 
riamente el trabajo. 

Una dificultad fundamental al establecer los requerimientos del sistema es que los proble- 
mas para los cuales se construyen los sistemas complejos son normalmente «problemas tra- 
viesos» (Rittel y Webber, 1973). Un «problema travieso» es un problema que es tan comple- 
jo, y en el que hay tantas entidades relacionadas, que no existe una especificacion definitiva 
del problema. La verdadera naturaleza de este emerge solo cuando sedesarrollauna solucion. 
Un ejemplo extremo de un «problema travieso» es la prevision de terremotos. Nadie puede 
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predecirde forma precisadonde sera el epicentro de un terremoto, en que momento ocurrira 
o que efecto tendra en el entorno local. Por lo tanto, no es posible especificar completamen- 
te como abordar un terremoto. El problema solo se puede abordar una vez que ha pasado. 



2.2.2 Diseno del slstema 

El diseno del sistema (Figura2.4) se centra en proporcionar la funcionalidad del sistema a tra- 
ves de sus diferentes componentes. Las actividades que se realizan en este proceso son: 

1. Dividir requerimientos. Analice los requerimientos y organiceios en grupos afines. 
Normalmente existen varias opciones posibles de division, y puede sugerir varias al- 
ternativas en esta etapa del proceso. 

2. Identificar subsistemas. Debe identificar los diferentes subsistemas quepueden, in- 
dividual o colectivamente, cumplir los requerimientos. Los grupos de requerimientos 
estan normalmente relacionados con los subsistemas, de tal forma que esta actividad 
y la de division de requerimientos se pueden fusionar. Sin embargo, la identificacion 
de subsistemas se puede ver influenciada por otros factores organizacionales y del en- 
torno. 

3. Asignar requerimientos a los subsistemas. Asigne los requerimientos a los subsiste- 
mas. Enprincipio, estodebe sersencillo si la division de requerimientos seutiliza para 
la identificacion de subsistemas. En la practica, no existe igualdad entre las divisiones 
de requerimientos y la identificacion de subsistemas. Las limitaciones de los subsis- 
temas comerciales pueden significar que tenga que cambiar los requerimientos para 
acomodarlos a estas restricciones. 

4. Especificar la funcionalidad de los subsistemas. Debe enumerar las funciones especi- 
ficas asignadas a cada subsistema. Esto puede verse como parte de la fase de diseno 
del sistema o, si el subsistema es un sistema de software, como parte de la actividad 
de especificacion de requerimientos para ese sistema. Tambien debe intentar especifi- 
car las relaciones entre los subsistemas en esta etapa. 

5 . Definir las interfaces del subsistema. Defina las interfaces necesarias y requeridas por 
cada subsistema. Una vez que estas interfaces se han acordado, es posible desarrollar 
estos subsistemas en paralelo. 

Como se indica en las flechas bidireccionales en la Figura 2.4, en este proceso de diseno 
existe mucha realimentacion e iteracion de una etapa a la otra. Cuando surgen problemas y 
preguntas, a menudo tiene que rehacer el trabajo hecho en etapas anteriores. 

Aunque se han separado los procesos de ingenieria de requerimientos y de diseno en este 
analisis, en la practica estan inextricablemente relacionados. Restricciones planteadas por sis- 
temas existentes pueden limitar elecciones de diseno, y estas elecciones pueden ser especifi- 
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cadas en los requerimientos. Puede tener que hacer algun disefio inicial para estracturar y or- 
ganizar el proceso de la ingenieria de requerimientos. A medida que el proceso de diseno con- 
tinua, puede descubrir problemas con los requerimientos existentes y pueden surgir nuevos re- 
querimientos. Por consiguiente, una manera de representar estos procesos relacionados es en 
forma de espiral, como se muestra en la Figura 2.5. 

El proceso en espiral refleja la realidad de que los requerimientos afectan a las decisiones 
de diseno y viceversa, y de esta forma tiene sentido entrelazar estos procesos. Comenzando 
en el centro, cada vuelta de la espiral anade algun detalle a los requerimientos y al diseno . A 1 - 
gunas vueltas se centran en los requerimientos; otras, en el diseno. A veces, nuevo conoci- 
miento recopilado durante los procesos de requerimientos y diseno significa que la declara- 
cion del problema en si misma tiene que ser cambiada. 

Para la mayoria de los sistemas, existen muchos diseflos posibles que cumplen los reque- 
rimientos. Estos comprenden una amplia gama de soluciones que combinan hardware, soft- 
ware y operaciones humanas. La solucion que elija para el desarrollo future debera ser la so- 
lucion tecnica mas apropiada que cumpla los requerimientos. Sin embargo, las intervenciones 
organizacionales y politicas pueden influir en la eleccion de la solucion. Por ejemplo, un clien- 
te del gobierno puede preferir usar proveedores nacionales antes que los extranjeros para su 
sistema, aun cuando el producto nacional sea tecnicamente inferior. Estas influencias nor- 
malmente tienen efecto en la fase de revision y valoracion en el modelo en espiral, donde los 
diseflos y requerimientos pueden ser aceptados o rechazados. El proceso finaliza cuando la 
revision y evaluacion muestra que los requerimientos y el diseflo de alto nivel son suficiente- 
mente detallados para permitir empezar la siguiente fase del proceso. 




Figura 2.5 Un modelo en espiral de requerimientos y diseno. 
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2.2.3 Modelado de slstemas 

Durante la actividad de requerimientos y diseno del sistema, estos pueden ser modelados 
como un conjunto de componentes y de relaciones entre estos componentes. Esto se puede 
ilustrargraficamente en un modelo arquitectonico del sistema, el cual proporciona al lector 
una vision general de la organizacion del sistema. 

La arquitectura del sistema puede se presentada como un diagrama de bloques que mues- 
tra los principales subsistemas y la interconexion entre ellos. Al dibujarun diagrama de blo- 
que, debe representar cada subsistema mediante un rectangulo, y debe mostrar las relaciones 
entre los subsistemas usando flechas que unan estos rectangulos. Las relaciones pueden ser 
flujo de datos, «utiliza»/«utilizado por» o algun otro tipo de relacion dependiente. 

Por ejemplo, en la Figura 2.6 se muestra la descomposicion de un sistema de alarma con- 
tra intrusos en sus componentes principales. El diagrama de bloques debe complementarse 
con una breve descripcion de cada subsistema, como se muestra en la Figura 2.7. 

En este nivel de detalle, el sistema se descompone en un conjunto de subsistemas que inter- 
actuan. Cada uno de estos debe ser representado de forma similar hasta que el sistema este di- 
vidido en componentes funcionales. Estos son componentes que, cuando se ven desde la 
perspectiva del subsistema, proporcionan una funcion unica. En contraste, un sistema co- 
munmente es multifuncional. Por supuesto, cuando se ve desde otra perspectiva (por ejem- 
plo, desde los componentes del fabricante), un componente funcional es un sistema. 

Historicamente, el modelo de arquitectura de sistemas fue utilizado para identificar com- 
ponentes de hardware y software que podian desarrollarse en paralelo. Sin embargo, esta dis- 
tincion hardware/software se ha hecho irrelevante. En la actualidad, la mayoria de los com- 
ponentes incluyen algunas capacidades de computo. Por ejemplo, las maquinas para enlazar 
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redes consisten en cables fisicos, repetidores y gateways. Estos incluyen procesadores y soft- 
ware para manejar estos procesadores, asi como componentes electronicos especializados. 

En el nivel de la arquitectura, es mas apropiado clasificar los subsistemas de acuerdo con 
su funcion antes de tomar decisiones sobre el tipo de hardware/software. La decision de pro- 
porcionaruna funcion mediante hardware o software depende de factores no tecnicos, como 
la disponibilidad de componentes comerciales o el tiempo disponible para desarrollar el com- 
ponente. 

Los diagramas de bloques se pueden utilizar para sistemas de cualquier tamano . La Figu- 
ra 2.8 muestra la arquitectura de un sistema de mayor tamano para el control del trafico ae- 
reo. Varios subsistemas principales mostrados son a su vez sistemas grandes. Las flechas que 
conectan estos sistemas muestran el flujo de informacion entre estos subsistemas. 



2.2.4 Desarrollo de los subsistemas 



Durante el desarrollo de los subsistemas, se implementan los que se hayan identificado du- 
rante el diseno del sistema. Esto implica comenzar otro proceso de la ingenieria de sistemas 
para los subsistemas individuates o, si el subsistema es software, un proceso de software que 
comprende requerimientos, diseno, implementacion y pruebas. 

Ocasionalmente, todos los subsistemas son desarrollados desde sus inicios durante el pro- 
ceso de desarrollo. Sin embargo, normalmente algunos de estos subsistemas son comerciales 
(COTS), los cuales se compran para integrarse en el sistema. Normalmente es mucho mas ba- 
rato comprarproductos existentes que desarrollar componentes de proposito especial. En esta 
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etapa, puede tenerque entrar de nuevo en la actividad de diseno para acomodar un componente 
comprado. Los sistemas COTS pueden no cumplir exactamente los requerimientos, pero, si los 
productos comerciales estan disponibles, es mucho mejor volver apensar el diseno. 

Es comun que los subsistemas se desarrollen en paralelo. Cuando se encuentran problemas 
que sobrepasan los limites del subsistema, se debe realizarunapeticionde modificacion del 
sistema. Si los sistemas requieren una amplia ingenieria del hardware, puede resultarmuy caro 
hacer modificaciones despues de haberse iniciado su fabricacion. A menudo se deben reali- 
zar «revisiones de trabajo» con el fin de detectar los problemas. Estas «revisiones de trabajo» 
comiinmente implican cambios en el software debido a la flexibilidad inherente a el. Esto con- 
duce a cambios en los requerimientos del software; por lo tanto, como se explico en el Capi- 
tulo 1, es importante disenar software para el cambio, de modo que puedan implementarse 
nuevos requerimientos sin un excesivo coste adicional. 

2.2.5 Integraclon del sistema 

Durante el proceso de integracion del sistema, se toman los subsistemas desarrollados de for- 
ma independiente y se conjuntan para crear el sistema completo. La integracion se puede ha- 
cer utilizando el enfoque del «bigbang», que consiste en integrar todos los subsistemas al mis- 
mo tiempo. Sin embargo, a efectos tecnicos y de administracion, el mejor enfoque es un 
proceso de integracion creciente donde los sistemas se integran uno a uno, por dos razones: 

1 . Por lo general, es imposible confeccionar una agenda para el desarrollo de todos los 
subsistemas de tal forma que todos terminen al mismo tiempo. 

2. La integracion creciente reduce el costo en la localizacion de errores. Si varios sub- 
sistemas se integran simultaneamente, un error que surja durante las pruebas puede es- 
tar en cualquiera de estos subsistemas. Cuado un unico subsistema se integra en un sis- 
tema en funcionamiento, los errores que se produzcan estaran probablemente en el 
subsistema recien integrado o en las interacciones entre los subsistemas existentes y 
el nuevo sistema. 

Una vez que los componentes han sido integrados, tiene lugar un extenso programa de 
pruebas del sistema. Estas pruebas pretenden probar las interfaces entre los componentes y el 
comportamiento del sistema en su totalidad. 

Los defectos de los subsistemas que son consecuencia de suposiciones invalidas en los 
otros subsistemas, a menudo aparecen durante la integracion del sistema. Esto puede condu- 
cir a problemas entre los diferentes contratistas responsables de los diferentes subsistemas. 
Cuando se descubren problemas en la interaccion de subsistemas, los diferentes contratistas 
pueden discutir sobre que subsistema es el defectuoso. Las negociaciones de como solucio- 
nar el problema pueden llevar semanas o meses. 

Como cada vez mas los sistemas son construidos por la integracion de componentes hard- 
ware y software COTS, la integracion de sistemas esta adquiriendo una importancia crecien- 
te. En algunos casos, no hay separacion en el desarrollo de subsistemas y la integracion es, 
esencialmente, la fase de implementacion del sistema. 

2.2.6 Evoluclon del sistema 

Los sistemas grandes y complejos tienen un periodo de vida largo. Durante su vida, se cam- 
bian para corregir errores en los requerimientos del sistema original y para implementar nue- 
vos requerimientos que surgen. Los sistemas de computo se reemplazan por nuevas maqui- 
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has mas rapidas. La organizacion que utilizael sistemapuede reorganizarse y utilizar el sis- 
tema de forma diferente. El entorno externo del sistema puede cambiar, forzando cambios en 
el sistema. 

La evolucion del sistema, como la del software (expuesta en el Capitulo 21), es inherente- 
mente costosa, por varias razones: 

1 . Los cambios propuestos tienen que analizarse cuidadosamente desde perspectivas tec- 
nicas y de negocios. Los cambios tienen que contribuir a los objetivos del sistema y 
no deben tener simplemente una motivacion tecnica. 

2. Debido a que los subsistemas nunca son completamente independientes, los cambios 
en uno pueden afectar de forma adversa al funcionamiento o comportamiento de otros. 
Por lo tanto, sera necesario cambiar estos subsistemas. 

3. A menudo no se registran las razones del diseflo original. Los responsables de la evo- 
lucion del sistema tienen que resolver por que se tomaron decisiones particulares de 
diseflo. 

4. Al paso del tiempo, su estructura se corrompe por el cambio de tal forma que se in- 
crementan los costos de cambios adicionales. 

Los sistemas que se han desarrollado con el tiempo dependen de tecnologias hardware y 
software obsoletas. Si tienen un papel critico en la organizacion, son conocidos como siste- 
mas heredados — sistemas que a la organizacion le gustaria reemplazar pero donde los ries- 
gos de introducirun nuevo sistema son altos — . En la Seccion 2.4 se tratan algunas cuestio- 
nes de los sistemas heredados. 

2.2.7 Desmantelamlento del sistema 

El desmantelamiento del sistema significa poner fuera de servicio a dicho sistema despues 
de que termina su periodo de utilidad operativa. Para sistemas hardware esto puede impli- 
car el desmontaje y reciclaje de materiales o el tratamiento de sustancias toxicas. El soft- 
ware no tiene problemas fisicos de desmantelamiento, pero algun software se puede in- 
corporar en un sistema para ayudar al proceso de desmantelamiento. Por ejemplo, el 
software se puede utilizarparacontrolarel estado de componentes hardware. Cuando el sis- 
tema se desmantela, los componentes en buen estado se pueden identificar y reutilizar en 
otros sistemas. 

Si los datos del sistema que se esta desmantelando todavia poseen valor para su organiza- 
cion, puede tener que convertirlos para utilizarlos en otros sistemas. A menudo esto implica 
un costo, ya que la estructura de datos puede estar implicitamente definida en el software mis- 
mo. Debe analizar el software para descubrir como estan estructurados los datos y entonces 
escribir un programa para reorganizarlos en las estructuras exigidas por el nuevo sistema. 

2.3 Organizaciones, personas y sistemas informaticos 

Los sistemas socio-tecnicos son sistemas empresariales que tiene la intencion de ayudar a con- 
seguir algunos objetivos organizacionales o de negocio. Esto puede ser incrementar las ven- 
tas, reducirel uso de material en la fabricacion, recaudar impuestos, mantenerun espacio ae- 
reo seguro, etc. Puesto que estan dentro de un entorno organizacional, la consecucion, 
desarrollo y uso de estos sistemas estan influenciados por las politicas y procedimientos de la 
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organizacion y por su cultura de trabajo. Los usuarios del sistema son personas que estan in- 
fluenciadas por la forma en la que es gestionada la organizacion y por sus relaciones con otras 
personas dentro y fuera esta. 

Por lo tanto, cuando esta intentando entender los requerimientos para un sistema socio- 
tecnico necesita entender su entorno organizacional. De lo contrario, los sistemas pueden 
no cumplir las necesidades del negocio, y los usuarios y sus directivos puede rechazar el 
sistema. 

Los factores humanos y organizacionales del entorno del sistema que afectan a su diseno son 
los siguientes: 

1 . Cambios en el proceso. ^,.E1 sistema requiere cambiar los procesos en el entorno? Si es 
asL se necesitara formacion. Si los cambios son significativos, o implican que la gen- 
te pierda su trabajo, existe el peligro de que los usuarios se resistan a la introduccion 
del sistema. 

2. Cambios en el trabajo. iE\ sistema inhabilita a los usuarios en un entorno o hace que 
cambie su forma de trabajar? Si es asi, se resistiran a la introduccion del sistema en 
laorganizacion. Los diseflos que implican un cambio en las formas de trabajo de los 
directivos con el fin de adaptarse al sistema informatico tienen sus implicaciones. 
Los directivos sienten que sujerarquia en la organizacion se ve reducida por el sis- 
tema. 

3. Cambios organizacionales. iE\ sistema cambia la estructura de poder en una organi- 
zacion? Por ejemplo, si una organizacion depende de un sistema complejo, aquellos 
que saben como operar el sistema tienen un gran poder politico. 

Estos factores humanos, sociales y organizacionales son a menudo criticos para determi- 
nar si un sistema cumple con exito sus objetivos. Desgraciadamente, predecir sus efectos so- 
bre los sistemas es una tarea dificil para los ingenieros que tienen poca experiencia en estu- 
dios sociales o culturales. Para ayudar a entender los efectos de los sistemas en las 
organizaciones, se han desarrollado varias metodologias, como la Sociotecnica de Mumford 
(Mumford, 1989)y laMetodologiade Sistemas Suavesde Checkland (Checklandy Scholes, 
1990; Checkland, 1981). Tambien existen amplios estudios sociologicos de (os efectos en el 
trabajo de los sistemas informaticos (Ackroyd et al., 1 992). 

De forma ideal, todo el conocimiento organizacional relevante debe incluirse en la espe- 
cificacion del sistema, de tal forma que los disenadores puedan tenerlo en cuenta. En reali- 
dad, esto es imposible. Los disenadores de sistemas tienen que hacer suposiciones basadas en 
otros sistemas comparables y en el sentido comun. Si sus suposiciones son erroneas, el siste- 
ma puede funcionar mal de forma impredecible. Por ejemplo, si los disenadores de un siste- 
ma no comprenden que las diferentes partes de una organizacion realmente pueden tener ob- 
jetivos contradictorios, entonces cualquier sistema que sea desarrollado para una organizacion 
inevitablemente tendra algun usuario insatisfecho. 

2.3.1 Procesos organizacionales 

En la Seccion 2.2, se introdujo el modelo de procesos de la ingenieria de sistemas que mos- 
tro los subprocesos implicados en el desarrollo del sistema. Sin embargo, el proceso de des- 
arrollo no es el unico proceso implicado en la ingenieria de sistemas. Este se relaciona con el 
proceso de adquisicion del sistema y con el proceso de uso y operacion del sistema, como se 
ilustra en la Figura 2.9. 
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El proceso de adquisicion normalmente esta contenido dentro de la organizacion que com- 
prara y usara el sistema (la organizacion cliente). El proceso de adquisicion del sistema esta 
relacionado con la toma de las decisiones sobre la mejor forma en la que una organizacion 
puede adquirir un sistema y decidir sobre los mejores proveedores de ese sistema. 

Los sistemas grandes y complejos comunmente consisten en una mezcla de componentes co- 
merciales y componentes construidos de forma especial. Una razon por la cual se incluye cada 
vez mas software en los sistemas es que permite una mayor utilizacion de los diferentes com- 
ponentes hardware existentes, donde el software actua como un «pegamento» para hacer que es- 
tos componentes hardware trabajen juntos de forma efectiva. La necesidad de desarrollar este 
«pegamento» se debe a que el ahorro por la utilizacion de los componentes comerciales no es 
tan grande como se supone. En el Capitulo 1 8 se tratan con mas detalle los sistemas COTS. 

La Figura 2.10 muestra el proceso de adquisicion tanto para sistemas existentes como para 
sistemas especialmente disenados. Algunos puntos importantes del proceso mostrado en este 
diagrama son los siguientes: 

1 . Comunmente los componentes comerciales no cumplen de forma exacta los requeri- 
mientos, a menos que estos se hayan escrito teniendo en cuenta dichos componentes. 
Por lo tanto, elegir un sistema significa que tiene que encontrar la correspondencia mas 
cercana entre los requerimientos del sistema y las funcionalidades ofrecidas por los 
sistemas comerciales. Puede tener entonces que modificar los requerimientos y esto 
puede producir efectos perturbadores en otros subsistemas. 

2. Cuando un sistema se construye de forma especial, la especificacion de requerimien- 
tos actua como la base de un contrato para la adquisicion del sistema. Es, por lo tan- 
to, un documento legal, y tambien tecnico. 

3. Una vez que se ha seleccionado un contratista para construir el sistema, existe un pe- 
riodo de negociacion del contrato en el cual puede tener que negociar nuevos cambios 
en los requerimientos y discutir temas como el costo de los cambios del sistema. 

Sistema comercial 
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Figura 2.10 El proceso de adquisicidn del sistema. 
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Se han resumido las fases principales del proceso de desarrollo del sistema. Los sistemas com- 
plejos normalmente son desarrollados poruna organizacion diferente (el proveedor) de la orga- 
nizacion que adquiere el sistema. La razon de esto es que rara vez el negocio del solicitante es 
el desarrollo de sistemas, por lo que sus empleados no tienen la capacidad necesaria para 
desarrollar por si mismos sistemas complejos. De hecho, muy pocas organizaciones tienen la ca- 
pacidad de desarrollar, fabricar y probar todos los componentes de un sistema largo y complejo. 

El proveedor, a quien normalmente se le conoce como el contratista principal, puede sub- 
contratar el desarrollo de diferentes subsistemas a un cierto numero de subcontratistas. Para 
sistemas grandes, como los de control del trafico aereo, un grupo de proveedores puede for- 
marun consorcio para competirpor el contrato. El consorcio debe incluir todas las capacida- 
des requeridas por este tipo de sistema, como proveedores de hardware, desarrolladores de 
software y proveedores de perifericos y de equipo especial, como radares. 

El solicitante trata con el contratista en vez de con los subcontratistas, por lo que hay una 
unica interfaz solicitante/proveedor. Los subcontratistas disefian y construyen partes del sis- 
tema de acuerdo con una especificacion producida por el contratista principal. Unavezcom- 
pletadas, el contratista principal integra estos componentes y los entrega al cliente que com- 
pra el sistema. Dependiendo del contrato, el solicitante puede permitir al contratista elegir 
libremente a los subcontratistas o puede exigirle que los elija de una lista aprobada. 

Los procesos operativos son los procesos que estan relacionados con el uso del sistema para 
su proposito definido. Por ejemplo, los operadores de un sistema de control del trafico aereo 
siguen procesos especificos cuando el avion entra y sale del espacio aereo, cuando tienen que 
cambiar la altura o la velocidad, cuando ocurre una emergencia, etc. Para sistemas nuevos, es- 
tos procesos operativos tienen que ser definidos y documentados durante el proceso de des- 
arrollo del sistema. Puede que los operadores tengan que formarse y haya que adaptar otros 
procesos de trabajo para hacer efectivo el uso del nuevo sistema. En esta etapa pueden surgir 
problemas no detectados, porque la especificacion del sistema puede contener errores u omi- 
siones. Mientras que el sistema puede funcionar conforme a la especificacion, sus funciones 
pueden no cumplir las necesidades operativas reales. Por consiguiente, es posible que los ope- 
radores no usen el sistema como sus disenadores pensaron. 

La ventaja clave de tener gente en un sistema es que esta tiene una capacidad unica para 
responder eficazmente a situaciones inesperadas, aun cuando no hayan tenido una experien- 
cia directa en estas situaciones. Por lo tanto, cuando las cosas van mal. los operadores pueden 
a menudo recuperar la situacion, aunque algunas veces esto pueda significar que no se cum- 
plan los procesos definidos. Los operadores tambien usan su conocimiento local para adap- 
tar y mejorar los procesos. Normalmente, el proceso operativo real es diferente del anticipa- 
do por los disenadores del sistema. 

Esto significa que los disenadores deben disenar los procesos operativos para ser flexibles 
y adaptables. Los procesos operativos no deben ser demasiado restrictivos, ni requerir opera- 
ciones hechas en un orden en particular, y el software del sistema no debe depender de que 
no se sigaun proceso especifico. Los operadores normalmente mejoran el proceso porque sa- 
ben que es lo que funciona y lo que no funciona en una situacion real. 

Una cuestion que puede surgir solamente despues de que el sistema entre en funciona- 
miento es el problema del funcionamiento del nuevo sistema junto a sistemas existentes. Es 
posible que existan problemas fisicos de incompatibilidad, o que sea dificil el transferir datos 
de un sistema al otro. Pueden surgir problemas mas sutiles debido a que diferentes sistemas 
tienen distintas interfaces de usuario. Introducir el nuevo sistema puede incrementar el indi- 
ce de error del operador para los sistemas existentes porque los operadores confunden los co- 
mandos de la interfaz de usuario. 
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Debido al tiempo y esfiierzo requeridos para desarrollarun sistema complejo, los grandes sis- 
temas informaticos normalmente tienen un tiempo de vida largo. Por ejemplo, los sistemas mi- 
litares son disenados normalmente para un tiempo de vida de 20 anos, y muchos de los siste- 
mas de control del trafico aereo del mundo todavia dependen de software y procesos 
operativos que fueron desarrollados en un principio en los anos 60 y 70. Algunas veces es de- 
masiado caro y peligroso descartar tales sistemas de negocio criticos despues de unos pocos 
anos de uso. Su desarrollo continua durante toda su vida con cambios para satisfacer nuevos 
requerimientos, nuevas plataformas operativas, y asi sucesivamente. 

Los sistemas heredados son sistemas informaticos socio-tecnicos que han sido desarro- 
llados en el pasado, a menudo usando una tecnologia antigua y obsoleta. Estos sistemas no 
solamente incluyen hardware y software sino tambien procesos y procedimientos hereda- 
dos — antiguas formas de hacercosas que son dificiles de cambiar porque dependen de soft- 
ware heredado — . Cambios en una parte del sistema inevitablemente implican cambios en 
otros componentes. 

Los sistemas heredados son a menudo sistemas de negocio criticos. Se mantienen porque 
es demasiado arriesgado reemplazarlos. Por ejemplo, para la mayoria de los bancos el siste- 
ma contable de clientes fue uno de los primeros sistemas. Las politicas y procedimientos or- 
ganizacionales pueden depender de este sistema. Si el banco fuera a descartar y reemplazar 
el sistema contable de clientes (el cual es posible que se ejecute en un costoso hardware main- 
frame), entonces habria un serio riesgo de negocio si el sistema de recambio no funcionara 
adecuadamente. Ademas, los procedimientos existentes tendrian que cambiar, y esto puede 
molestar a las personas de la organizacion y causar dificultades con los auditores del banco. 

La Figura 2.11 ilustra las partes logicas de un sistema heredado y sus relaciones: 

1 . Sistema hardware. En muchos casos, los sistemas heredados se crearon para hardware 
mainframe que ya no esta disponible, es costoso de mantener y no es compatible con 
las actuales politicas de compras de IT organizacionales. 

2. Software de apoyo. Los sistemas heredados cuentan con una gran variedad de soft- 
ware de apoyo que van desde sistemas operativos y utilidades suministradas por el 
fabricante de hardware hasta los compiladores utilizados para el desarrollo de siste- 
mas. De nuevo, estos pueden ser obsoletos o ya no recibir soporte de sus proveedo- 
res originales. 

3. Software de aplicacion. El sistema de aplicacion que proporciona los servicios del ne- 
gocio por lo general esta compuesto de varios programas independientes desarrolla- 
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dos en momentos diferentes. Algunas veces, el termino sistema heredado significa este 
software de aplicacion en lugar del sistema completo. 

4. Dalos de aplicacion. Son los datos procesados por el sistema de aplicacion. En mu- 
chos sistemas heredados, se ha acumulado un inmenso volumen de datos a lo largo del 
tiempo de vida del sistema. Estos datos pueden ser incongruentes y estar duplicados 
en varios archivos. 

5. Procesos de negocio. Son los procesos utilizados en los negocios para lograr algun ob- 
jetivo del negocio. Un ejemplo de un proceso de negocio en una compafna de seguros 
seria emitirunapolitica de seguros; en una fabrica, un proceso de negocio seriaacep- 
tar un pedido para los productos y estipular el proceso de fabricacion asociado. Los 
procesos de negocio pueden ser disenados alrededor de un sistema heredado y res- 
tringidos por la funcionalidad que este proporciona. 

6. Politicasy regias de negocio. Son las definiciones de como llevar a cabo los negocios 
y las restricciones sobre estos. La utilizacion del sistema de aplicacion heredado esta 
contenida en estas politicas y regias. 

Una forma alternativa de observar estos componentes de un sistema heredado es como una 
serie de capas, segun se muestra en la Figura 2.12. Cada capa depende de la capa inmediata- 
mente inferior y tiene una interfaz con esa capa. Si las interfaces se mantienen, entonces po- 
drian hacerse cambios dentro de una capa sin afectar a las adyacentes. 

En la practica, esta vision simple rara vez funciona, y los cambios en una capa del sistema 
requieren cambios consecuentes en las capas inferiores y superiores al nivel que se cambian. 
Las razones de esto son las siguientes: 

1. Cambiar una capa en el sistema puede introducir nuevos recursos, y las capas mas al- 
tas en el sistema se pueden entonces cambiar para aprovechar estos recursos. Por 
ejemplo, introducir una nueva base de datos en la capa del software de apoyo puede 
incluir recursos para acceder a los datos a traves de una navegador web, y los proce- 
sos de negocio pueden ser modificados para aprovechar este recurso. 

2. Cambiar el software puede ralentizar el sistema, por lo que se necesita un nuevo hard- 
ware para mejorar el rendimiento del sistema. El incremento en el rendimiento a par- 
tir del nuevo hardware puede significar que los cambios de software adicionales que 
anteriormente no eran practicos ahora son posibles. 

3. A menudo, es imposible dar mantenimiento a las interfaces de hardware, especial- 
mente si se propone un cambio radical a un nuevo tipo de hardware. Por ejemplo, si 
una compania pasa de un hardware mainframe a sistemas cliente-servidor (discutidos 
en el Capitulo 11), estos por lo general tienen diferentes sistemas operativos. Por lo 
tanto, se pueden requerir cambios mayores en el software de aplicacion. 
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PUNTOS CLAVE 

• Los sistemas socio-tecnicos incluyen hardware, software y personas, y se situan dentro de una organizacion. 
Estan disehadospara ayudara la organizacion a cumplir a Igu n objetivo amplio. 

• Las propiedades emergentes de un sistema son caracteristicas de Eos sistemas como un todo mas que sus par- 
tes componentes. Incluyen propiedades como el rendimiento, la Habilidad, la usabilidad, (a seguridad y la pro- 
teccion. El exito o fracaso de un sistema depende a menudo de estas propiedades emergentes. 

• El proceso de la ingenieria de sistemas comprende la especificacion, el diseno, el desarrollo, la integracion y 
las pruebas. La integracion de sistemas es critica cuando diversos subsistemas de diferentes proveedores de- 
ben trabajar de manera conjunta. 

• Factores humanos y organizacionales como la estructura y politicas organizacionales influyen de forma signi- 
ficativa enelfuncionamientodelos sistemas socio-tecnicos. 

• Dentro de una organizacion, existen complejas relaciones entre losprocesosdeadquisicion,desarrolloyope- 
rativo del sistema. 

• Un sistema heredado es un sistema antiguo que aim proporciona servicios esenciales de negocio. 

• Los sistemas heredados no son solo sistemas de software de aplicacion. Son sistemas socio-tecnicos, por lo 
que incluyen procesos de negocio, software de aplicacion, software de apoyo y sistema hardware. 



«Software system engineering: A tutorial». Una buena vision general de la ingenieria de sistemas, aunque Thayer 
se centra exclusivamente en los sistemas informaticos y no trata asuntos socio-tecnicos. (R. H. Thayer, IEEE Com- 
puter, abril 2002.) 

«Legacy information systems: Issues and directions)). Una vision general de losproblemas de los sistemas hereda- 
dos con atencion particular a los problemas de datos heredados. O- Bisbal ef ai, IEEE Software, septiembre-octu- 
bre 1999.) 

Systems Engineering: Coping with Complexity. En el momenta de escribir la presente obra, este era aun el mejor li- 
bra de ingenieria de sistemas disponible. Se centra en los procesos de la ingenieria de sistemas con buenos capi- 
tulos sobre requerimientos, arquitectura y gestion de proyectos. (R. Stevens etai, 1998, Prentice-Hall.) 

«Airport 95: Automated baggage system». Un caso de estudio excelente y legible de lo que puede resultar mal en 
un proyecto de ingenieria de sistemas y como el software tiende a tener la culpa de los grandes fallos de los siste- 
mas. (ACA/I Software Engineering Notes, 21 de marzo de 1996.) 
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21 Explique que otros sistemas dentro del entorno del sistema pueden tener efectos no previstos en su fun- 
cionamiento. 
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Explique por que especificar un sistema para ser utilizado por los servicios de emergencia en la gestion de 
desastres es un problema travieso. 

Mencione la manera en que los sistemas de software utilizados en un automovil pueden ayudar al des- 
mantelamiento (desechos) del sistema completo. 

Explique por que es importante presentaruna descripcion completa de una arquitectura del sistema en una 
etapa inicial del proceso de especificacion del sistema. 

Considere un sistema de seguridad que es una version extendida del sistema mostrado en la Figura 2.6, que 
esta pensado para proteger contra (a intrusion y para detectar fuego. Contiene sensores de humo, de movi- 
miento y de puertas, videocamaras controladas por computadora, que se encuentran en varios lugares del 
edificio, una consola de operacion donde se informa del estado del sistema, y facilidades de comunicacion 
externa para llamar a los servicios apropiados como la policia y los bomberos. Dibuje un diagrama de blo- 
ques de un posible diseno de dicho sistema. 

Se construye un sistema de deteccion de inundaciones para avisar de posibles inundaciones en lugares 
que se ven amenazados por estas. El sistema incluira un conjunto de sensores para vigilar el cambio en los 
niveles del rio, vinculos a un sistema meteorologico que proporciona la prevision del tiempo, vinculos a los 
sistemas de comunicacion de los servicios de emergencia (policia, guardacostas, etc.), monitores de video 
instalados en lugares especificos, un cuarto de control equipado con consolas de operacion y monitores 
de video. 

Los consoladores pueden accedera la informacion de la base de datos y emitirpantallas de video. El sis- 
tema de base de datos incluye informacion de los sensores, la ubicacion de los sitios en riesgo y las condi- 
ciones de amenaza para estos sitios (por ejemplo, marea alta, vientos del suroeste, etc.), tablas de las ma- 
reas para los sitios costeros, el inventario y localizacion del equipo de control de inundaciones, detalle de 
los contactos de los servicios de emergencia, estaciones locales de radio, etc. 

Dibuje un diagrama de bloques de una posible arquitectura para dicho sistema. Debe identificar los sub- 
sistemas principales y los vinculos entre ellos. 

Un consorcio de museos europeos va a desarrollar un sistema multimedia de museo virtual que ofrece ex- 
periencias virtuales de la Grecia antigua. El sistema debe proporcionar a los usuarios la funcion de ver mo- 
deles 3-D de la Grecia antigua a traves de un navegador web estandary tambien debe apoyar una expe- 
riencia de realidad virtual. ^Que dificultades politicas y organizacionales pueden surgir cuando el sistema 
se instale en los museos que forman el consorcio? 

Explique por que los sistemas heredados pueden ser criticos en el funcionamiento de un negocio. 

Explique por que los sistemas heredados pueden causar dificultades para las companias que desean reor- 
ganizar sus procesos de negocio. 

^Cuales son los argumentos a favor y en contra para considerar que la ingenieria de sistemases una profe- 
sion, como la ingenieria electrica o la de software? 

Suponga que es un ingeniero relacionado con el desarrollo de un sistema financiero. Durante la instalacion, 
descubre que el sistema hara que se prescindan de muchas personas. La gente del entorno le niega el ac- 
ceso a informacion esencial para completar La instalacion del sistema. ^Hasta donde deberia, como inge- 
niero de sistemas, verse envuelto en esto? ^,Es responsabilidad suya completar la instalacion como lo esti- 
pula el contrato? ^Deberia abandonar el trabajo hasta que la organizacion haya resuelto el problema? 
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Objetivos 

El objetivo de este capitulo es introducir el concepto de sistema 
critico, cuya caracteristica mas importante es la confiabilidad. 
Cuando haya leido este capitulo: 

• comprendera que en un sistema critico un fallo de 
funcionamiento del sistema puede tener graves consecuencias 
humanas o economicas; 

• comprendera las cuatro dimensiones de la confiabilidad de un 
sistema: disponibilidad, fiabilidad, seguridady proteccion; 

• comprendera que para lograr la confiabilidad se tienen que 
evitar los errores durante el desarrollo de un sistema, detectar 
y eliminar errores cuando el sistema se esta utilizando y 
limitar el dano ocasionado por fallos operacionales. 

Contenidos 

3.1 Un sistema de segundad critico sencillo 

3.2 Confiabilidad de un sistema 

3.3 Disponibilidad y fiabilidad 

3.4 Seguridad 

3.5 Proteccion 
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Los fallos de funcionamiento del software son relativamente comunes. En la mayoria de los 
casos, estos fallos provocan molestias, pero no daflos graves ni a largo plazo. Sin embargo, en 
algunos sistemas un fallo de funcionamiento puede ocasionarperdidas economicas significa- 
tivas, dafto fisico o amenazas a la vida humana. Estos sistemas se conocen como sistemas cri- 
ticos. Los sistemas criticos son sistemas tecnicos o socio-tecnicos de los cuales dependen las 
personas o los negocios. Si estos sistemas no ofrecen sus servicios de la forma esperada, pue- 
den provocar graves problemas y perdidas importantes. 
Hay tres tipos principales de sistemas criticos: 

1. Sistemas de seguridad criticos. Son sistemas cuyo fallo de funcionamiento puede pro- 
vocar perjuicio, perdida de vidas o danos graves al medio ambiente. Un ejemplo de un 
sistema de seguridad critico es un sistema de control para una planta de fabricacion de 
productos quimicos. 

2. Sistemas de mision criticos. Son sistemas cuyo fallo de funcionamiento puede provo- 
car errores en algunas actividades dirigidas por objetivos. Un ejemplo de un sistema 
de mision critico es un sistema de navegacion para una nave espacial. 

3. Sistemas de negocio criticos. Son sistemas cuyo fallo de funcionamiento puede pro- 
vocar costes muy elevados para el negocio que utiliza un sistema de este tipo. Un ejem- 
plo de un sistema de negocio critico es un sistema de cuentas bancarias. 

Lapropiedad mas importante de un sistema critico es su confiabilidad. El termino confia- 
bilidad fue propuesto por Laprie (Laprie, 1995) para hacer referencia a las siguientes propie- 
dades relacionadas de los sistemas: disponibilidad, fiabilidad, seguridad y proteccion. Tal y 
como se indica en la Seccion 3.2, estas propiedades estan enlazadas inextricablemente; por lo 
tanto, tener un unico termino para referirse a todas ellas tiene sentido. 

Existen varias razones por las que la confiabilidad es la propiedad mas importante de los 
sistemas criticos: 

1 . Los sistemas que son no fiables, inseguros o desprotegidos son rechazados a me- 
nu do por sus usuarios. Si los usuarios no confian en un sistema, se negaran a utili- 
zarlo. Es mas, tambien rehusaran compraro utilizar productos de la misma compa- 

flia que produjo el sistema no confiable, puesto que creen que estos tampoco son 
confiables. 

2. Los costes de los fallos de funcionamiento del sistema pueden ser enormes. En algu- 
nas aplicaciones, como un sistema de control de reactores o un sistema de navegacion 
aerea, el coste de un fallo en el sistema es mayor en varios ordenes de magnitud que 

el coste de dicho sistema de control. 

3. Los sistemas no confiables pueden provocar perdida de information. Es muy cara la 
captura y mantenimiento de los datos; algunas veces cuesta mas que el sistema infor- 
matico que los procesa. Se tiene que hacer un gran esfuerzo e invertir mucho dinero 
para duplicar los datos importantes a fin de protegerlos de cualquier corrupcion. 

El elevado coste de un fallo de funcionamiento en los sistemas criticos implica que se de- 
ben usar metodos y tecnicas confiables en su desarrollo. Como consecuencia, los sistemas cri- 
ticos generalmente se desarrollan utilizando tecnicas muy probadas en lugar de tecnicas no- 
vedosas que no han sido objeto de una extensa experienciapractica. En vez de utilizar metodos 
y tecnicas novedosas, los desarrolladores de sistemas criticos son conservadores por natura- 
leza. Prefieren utilizar tecnicas antiguas cuyas ventajas e inconvenientes son muy conocidos, 
en lugar de nuevas tecnicas que aparentemente son mejores pero cuyos problemas a largo pla- 
zo se desconocen. 
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Para el desarrollo de sistemas criticos, a menudo se utilizan tecnicas de ingenieria del soft- 
ware que por lo general no son rentables. Por ejemplo, los metodos matematicos formales de 
desarrollo de software (vistos en el Capitulo 10) han sido usados con exito para sistemas cri- 
ticos seguros y protegidos (Hall. 1996; Hall y Chapman. 2002). Unarazon por la que se usan 
estos metodos formales es que ayudan a reducir la cantidad de praebas requeridas. Para sis- 
temas criticos, los costes de verificacion y validacion generalmente son muy elevados — mas 
del 50% de los costes totales de desarrollo del sistema. 

Si bien un numero reducido de sistemas se pueden automatizar completamente, la mayo- 
ria de los sistemas criticos son sistemas socio-tecnicos en los que las personas monitorizan y 
controlan el funcionamiento de dichos sistemas informaticos. Los costes de un fallo de fun- 
cionamiento de los sistemas criticos generalmente son tan altos que es necesario contar con 
personal adicional en el sistema que pueda hacer frente a situaciones inesperadas, y que pue- 
da recuperar el funcionamiento normal del sistema cuando las cosas van mal. 

Desde luego, a pesar de que los operadores del sistema pueden ayudar a recuperarlo cuan- 
do algo va mal. ellos mismos a su vez pueden generar problemas si cometen errores. Existen 
tres tipos de «componentes de sistemas» susceptibles de generar un fallo en el sistema: 

1 . El hardware del sistema puede fallar debido a errores en su diseno, tambien debido a 
que los componentes fallan como resultado de errores de fabricacion, o debido a que 
dichos componentes han llegado al final de su vida util. 

2. El software del sistema puede fallar debido a errores ensuespecificacion, diseno o im- 
plementacion. 

3. Los operadores del sistema pueden provocar fallos en el sistema debido a un uso in- 
correcto del mismo. Asi como el hardware y el software son cada vez mas fiables, hoy 
en dia los fallos debidos a un mal uso del sistema son probablemente la principal cau- 
sa de fallos de funcionamiento en el sistema. 

Estos fallos pueden interrelacionarse. Un componente hardware que deja de funcionar 
puede implicar que los operadores del sistema tengan que afrontar una situacion inesperada 
y una carga de trabajo adicional. Esto hace que los operadores trabajen en estado de estres y 
las personas que sufren estres a menudo cometen errores. Esto puede ocasionar que el soft- 
ware falle, lo que supone mas trabajo para los operadores, mas estres, y asi sucesivamente. 

Como resultado de todo lo anterior, es particularmente importante que los disefiadores de 
los sistemas criticos adopten una perspectiva holtstica del sistema en lugar de centrarse en un 
unico aspecto del mismo. SI el hardware, el software y las formas de utilizacion del sistema 
se disenan de forma separada sin tener en cuenta los puntos debiles potenciales del resto de 
las partes del sistema, entonces sera mas probable que los errores se produzcan en las inter- 
faces entre las distintas partes del sistema. 

3.1 Un sistema de seguridad critico sencillo 

Hay muchos tipos de sistemas informaticos criticos, desde sistemas de control para disposi- 
tivosy maquinarias hasta sistemas de informaciony comercio electronico. Estos podrian ser 
excelentes casos de estudio para un libro de ingenieria del software, ya que con frecuencia se 
usan en su desarrollo tecnicas avanzadas de ingenieria del software. Sin embargo, compren- 
der estos sistemas puede resultar muy dificil, puesto que es necesario comprender las carac- 
teristicas y restricciones del dominio de la aplicacion en el que operan. 
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Como consecuencia, el caso de estudio sobre sistemas criticos que uso en varios capitulos 
en este libro es un sistema medico que simula el funcionamiento del pancreas (un organo inter- 
no). He elegido este porque todos nosotros tenemos algun conocimiento acerca de problemas 
medicos y esta claro porque la seguridad y la fiabilidad son tan importantes para este tipo de 
sistemas. Se pretende que el sistema elegido ayude a las personas que padecen diabetes. 

La diabetes es una enfermedad relativamente comun en la cual el cuerpo humano no es 
capaz de producir suficiente cantidad de una hormona llamada insulina. La insulina meta- 
boliza la glucosa en la sangre. El tratamiento convencional de la diabetes comprende in- 
yecciones frecuentes de insulina fabricada geneticamente. Los diabeticos miden sus nive- 
les de azucar en la sangre usando un medidor externo y calculan la dosis de insulina que 
deberian inyectarse. 

El problema de este tratamiento es que el nivel de insulina en la sangre no depende sola- 
mente del nivel de glucosa en la sangre, sino que tambien depende del momento en el que se 
inyecto la insulina. Esto puede conducir a niveles muy bajos de glucosa en la sangre (si hay 
demasiada insulina) o niveles muy altos de azucar en la sangre (si hay muy poca insulina). 
Una bajada de azucar en la sangre constituye, a corto plazo, un problema mas serio, ya que 
puede ocasionar un mal funcionamiento del cerebro de forma temporal y, en ultima instancia, 
provocar la inconsciencia y la muerte. A largo plazo, un nivel alto continuado de azucar en la 
sangre puede conducir a danos en los ojos, en los rinones, y problemas de corazon. 

Los avances de hoy en dia en el desarrollo de sensores miniaturizados hacen posible el des- 
arrollo de sistemas de suministro automatico de insulina. Estos sistemas monitorizan el nivel 
de azucar en la sangre y suministran la dosis adecuada de insulina en el momento en el que 
se necesita. Los sistemas de suministro de insulina como el mencionado ya existen para el tra- 
tamiento de pacientes en hospitales. En el futuro, sera posible para muchos diabeticos llevar 
dichos sistemas de forma permanente adheridos a su cuerpo. 

Un sistema de suministro de insulina controlado por software funciona utilizando un mi- 
crosensor incrustado en el paciente para medir algun parametro de la sangre que sea propor- 
cional al nivel de azucar. Dicha informacion es enviada al controlador de la bomba. El con- 
trolador calcula el nivel de azucar y la cantidad de insulina que se necesita. A continuacion 
envia senales a una bomba miniaturizada para suministrar la insulina a traves de una aguja ad- 
herida permanentemente en el paciente. 

La Figura 3.1 muestra los componentes y la organizacion de la bomba de insulina. 
La Figura 3.2 muestra un modelo de flujo de datos que ilustra como una entrada de un 
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nivel de azucar en la sangre se transforma en una secuencia de comandos de control de 
la bomba. 

Hay dos requerimientos de alto nivel de confiabilidad para este sistema de bomba de in- 
sulina: 

1. El sistema debera estar disponible para suministrar insulina cuando sea necesario. 

2. El sistema debera funcionar de forma fiable y suministrar la cantidad correcta de in- 
sulina para contrarrestar el nivel actual de azucar en la sangre. 

Un fallo en el sistema podria, enprincipio, provocar que se suministren dosis excesivasde 
insulina, y esto constituiria una amenaza para la vida del paciente. Es particularmente impor- 
lanle que no se produzcan sobredosis de insulina. 



3.2 Confiabilidad de un sistema 

Todos estamos familiarizados con los problemas derivados de un fallo de funcionamiento en 
el sistema informatico. Por alguna razon no obvia, a veces los sistemas informaticos caen y 
no consiguen realizar los servicios que se les ha requerido. Los programas que se ejecutan so- 
bre dichos sistemas pueden no funcionar como se esperaba y, ocasionalmente, pueden co- 
rromper los datos que son gestionados por el sistema. Hemos aprendido a vivircon este tipo 
de fallos, y pocos de nosotros confiamos plenamente en las computadoras personales que nor- 
malmente usamos. 

La confiabilidad de un sistema informatico es una propiedad del sistema que es igual a su 
fidelidad. La fidelidad esencialmente significa el grado de confianza del usuario en que el sis- 
tema operaratal y como se esperade el y que no «fallara» al utilizarlo normalmente. Esta pro- 
piedad no se puede expresar numericamente, sino que seutilizanterminos relativos como «no 
confiable», «muy confiable» y «ultraconfiable» para reflejar los grados de confianza que po- 
driamos tener en un sistema. 

Grado de confianza y grado de utilidad no son, desde luego, lo mismo. Yo no creo que el 
procesador de textos que he usado para escribir este libro sea un sistema muy confiable, pero 
es muy util. Sin embargo, para reflejar mi falta de confianza en el sistema frecuentemente al- 
maceno mi trabajo y mantengo multiples copias de seguridadde el. Por lo tanto, compenso la 
falta de confianza en el sistema con acciones que limitan el dano que podria ocasionarse por 
una caida del sistema. 
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Existen cuatro dimensiones principales de la confiabilidad, tal y como se muestraen la Fi- 
gura 3.3: 

1. Disponibilidad: Informalmente, la disponibilidad de un sistema es la probabilidad de 
que este activo y en funcionamiento y sea capaz de proporcionar servicios utiles en 
cualquier momento. 

2. Fiabilidad: Informalmente, la fiabilidad de un sistema es la probabilidad de que, du- 
rante un determinado periodo de tiempo, el sistema funcione correctamente tal y como 
espera el usuario. 

3. Seguridad: Informalmente, la seguridad de un sistema es una valoracion de la proba- 
bilidad de que el sistema cause danos a las personas o a su entorno. 

4. Protection: Informalmente, la proteccion de un sistema es una valoracion de la pro- 
babilidad de que el sistema pueda resistir intrusiones accidentales o premeditadas. 

Las propiedades anteriores pueden descomponerse a su vez en otras propiedades mas 
simples. Por ejemplo, \aproteccion incluye la integridad (asegurar que el programa y los da- 
tes de los sistemas no resultan danados) y la confldencialidad (asegurar que solo las perso- 
nas autorizadas puedan acceder a la informacion). Lafiabilidad incluye la correccion (ase- 
gurar que los servicios que proporciona el sistema son los que se han especificado), /wc/moh 
(asegurar que la informacion se proporciona al usuario con el nivel de detalle adecuado), y 
oportunidad (asegurar que la informacion que proporciona el sistema se hace cuando es re- 
querida). 

Las propiedades de la confiabilidad ya mencionadas de disponibilidad, seguridad, fiabi- 
lidad y proteccion estan interrelacionadas. El funcionamiento de un sistema seguro depen- 
de normalmente de que el sistema este disponible y su funcionamiento sea fiable. Un sis- 
tema puede convertirse en no fiable debido a que sus datos han sido corrompidos por algun 
intruso. Los ataques de denegacion de servicio en un sistema tienen como proposito com- 
prometer su disponibilidad. Si un sistema que ha demostrado ser seguro es infectado por un 
virus, ya no se le puede suponer un funcionamiento seguro. Estas interrelaciones entre las 
cuatro propiedades son la razon de introducir la nocion de confiabilidad como una propie- 
dad que las engloba. 

Ademas de estas cuatro dimensiones principales, tambien se pueden considerar otras pro- 
piedades del sistema incluidas en el termino confiabilidad: 

1. Reparabilidad. Los fallos de funcionamiento del sistema son inevitables, pero la in- 
terrupcion causada por estos fallos se puede minimizar si el sistema se puede repa- 
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rarrapidamente. Para que esto ocurra, debe serposible diagnosticarelproblema, ac- 
ceder al componente que ha fallado y realizar los cambios para reparar ese compo- 
nente. La reparabilidad del software se mejora cuando se tiene acceso al codigo 
fuente y se tiene personal con destreza para realizar cambios sobre el. Desgraciada- 
mente, esto es cada vez menos frecuente a medida que nos movemos hacia el des- 
arrollo de sistemas que utilizan componentes comprados a terceros o cajas negras 
(vease el Capitulo 19). 

2. Mantenibilidad. A medida que se usan los sistemas, surgen nuevos requerimientos. Es 
importante mantener la utilidad de un sistema cambiandolo para adaptarlo a estos nue- 
vos requerimientos. Un software mantenible es un software que puede adaptarse para 
tener en cuenta los nuevos requerimientos con un coste razonable y con una baja pro- 
babilidad de introducir nuevos errores en el sistema al realizar los cambios corres- 
pondientes. 

3 . Supervivencia. Una caracteristica muy importante de los sistemas basados en Internet 
es la supervivencia, que esta estrechamente relacionada con la seguridad y la disponi- 
bilidad (Ellison etal.. 1999}. La supervivencia es la capacidad de un sistema para con- 
tinuar ofreciendo su servicio mientras esta siendo atacado y, potencial mente, mientras 
parte del sistema esta inhabilitado. Las tareas de supervivencia se centran en la iden- 
tificacion de componentes del sistema claves y en asegurar que estos pueden ofrecer 
un servicio de funcionamiento minimo. Se utilizan tres estrategias para asegurar que 
el sistema pueda continuar funcionando con un servicio minimo, a saber: resistencia 
al ataque, reconocimiento del ataque y recuperacion de danosocasionadosporun ata- 
que (Ellison et ai.. 1999; Ellison etal, 2002). 

4. Tolerancia a errores. Esta propiedad puede considerarse como parte de la usabilidad 
(explicada en el Capitulo 16) y refleja hasta que punto el sistema ha sido disenado para 
evitar y tolerar un error en la entrada de datos del usuario al sistema. Cuando se pro- 
ducen errores porpane del usuario, el sistema deberia, en la medida de lo posible, de- 
tectar estos errores y repararlos de forma automatica o pedir al usuario que vuelva a 
introducir sus datos. 

Debidoaque ladisponibilidad, fiabilidad, seguridad y proteccion sonpropiedades funda- 
mentales de la confiabilidad, me he centrado en ellas en este capitulo y en posteriores capi- 
tulos que tratan laespecificacionde sistemas criticos (Capitulo 9), desarrollo de sistemas cri- 
ticos (Capitulo 20) y validacion de sistemas criticos (Capitulo 24). 

Desde luego, estas propiedades de confiabilidad no son aplicables a todos los sistemas. 
Para el sistema de bomba de insulina, presentado en la Seccion 3.1, las propiedades mas im- 
portantes son disponibilidad (debe estar en funcionamiento cuando sea requerido), fiabilidad 
(debe suministrar la dosis correcta de insulina) y seguridad (nunca debe suministrar una do- 
sis peligrosa de insulina). La proteccion, en este caso, es menos probable que sea una cues- 
tion clave, ya que la bomba no mantiene informacion confidencial y no esta conectada a la 
red, por lo que no puede ser atacada de forma maliciosa. 

Los disenadores normalmente deben buscarun equilibrio entre el rendimiento del sistema 
y su confiabilidad. Por lo general, niveles altos de confiabilidad solamente pueden alcanzar- 
se acosta del rendimiento de! sistema. Un software confiable incluye codigo extra, a menu- 
do redundante, para realizar las comprobaciones necesarias para estados excepcionales del sis- 
tema y para recuperar el sistema ante un fallo. Esto reduce la confiabilidad del sistema e 
incrementa la cantidad de memoria requerida por el software. Ademas, tambien se incre- 
mentan de forma significativa los costes del desarrollo del sistema. 
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Debido al diseno adicional, implementacion y costes de validacion, el incremento de la 
confiabilidad de un sistema puede hacer crecer significativamente los costes de desarrollo. En 
particular, los costes de validacion son elevadospara los sistemas criticos. Ademas de validar 
que el sistema cumple con sus requerimientos, el proceso de validacion tiene que comprobar 
que el sistema es confiable a traves de un sistema de regulacion externo, como por ejemplo la 
Autoridad Federal de Aviacion. 

La Figura 3.4 muestra la relacion entre los costes y las mejoras crecientes en la confiabi- 
lidad. Cuanto mayor sea la confiabilidad que se necesita, mas habra que gastar en probar y 
chequearque efectivamente se ha alcanzado dicho nivel de confiabilidad. Debido al caracter 
exponencial de esta curva coste/confiabilidad, no es posible demostrarque un sistema es to- 
talmente confiable, ya que los costes necesarios para asegurar esto podrian ser infinitos. 

33 Disponibilidad y fiabilidad 

La disponibilidad y fiabilidad de un sistema son propiedades que estan estrechamente rela- 
cionadas y que pueden expresarse como probabilidades numericas. La fiabilidad de un siste- 
ma es la probabilidad de que el sistema funcione correctamente tal y como se ha especifica- 
do. La disponibilidad de un sistema es la probabilidad de que el sistema este en disposicion 
de funcionar para proporcionar los servicios a los usuarios que lo soliciten. 

Si bien estas dos propiedades guardan una estrecha relacion, no se puede deducir que los 
sistemas fiables estaran siempre disponibles y viceversa. Por ejemplo, algunos sistemas pue- 
den tener como requisito una disponibilidad alta, pero una fiabilidad mucho mas baja. Si los 
usuarios esperan un servicio continuo, entonces los requerimientos de disponibilidad son al- 
tos. Sin embargo, si las consecuencias de un fallo de funcionamiento son minimas y el siste- 
ma puede recuperarse rapidamente de dichos fallos, entonces el mismo sistema puede tener 
requerimientos de fiabilidad bajos. 

Un ejemplo de un sistema en el que la disponibilidad es mas criticaque la fiabilidad esuna 
centralita telefonica. Los usuarios esperan escuchar un tono cuando descuelgan el telefono, 
de forma que el sistema requiere un alto nivel de disponibilidad. Sin embargo, si un defecto 
en el sistema hace que la conexion termine, esta es a menudo recuperable. Los conmutadores 
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de las centralitas normalmente incluyen facilidades para reiniciar el sistema y volver a inten- 
tar establecer la conexion. Esto puede realizarse de forma muy rapida, y el usuario puede in- 
cluso no darse cuenta de que ha ocurrido un fallo de funcionamiento. Por lo tanto, la dispo- 
nibilidad es el requerimiento clave en estos sistemas en vez de la fiabilidad. 

Una diferencia adicional entre estas caracteristicas es que la disponibilidad no depende 
simplemente del sistema en si, sino tambien del tiempo necesario para reparar los defectos 
que hicieron que el sistema dejara de estar disponible. Por ello, si un sistema A falla una vez 
al aflo, y un sistema B falla una vez al mes, entonces A claramente es mas fiable que B. Sin 
embargo, supongase que el sistema A tarda tres dias en recuperarse despues de un fallo, 
mientras que B tarda 10 minutos en re inicial izarse. La disponibilidad deB a lo largo delafio 
(120 minutos de tiempo sin servicio) es mucho mejorque la del sistema A (4.230 minutos 
sin servicio). 

La fiabilidad y la disponibilidad de un sistema se pueden definir de forma mas precisa 
como sigue: 

1. Fiabilidad. La probabilidad de que se tengan operaciones libres de caidas durante un 
tiempo definido en un entorno dado para un proposito especifico. 

2. Disponibilidad. La probabilidad de que un sistema, en cierto momenta, este en fun- 
cionamiento y sea capaz de proporcionar los servicios solicitados. 

Uno de los problemas practicos en el desarrollo de sistemas fiables es que nuestras nocio- 
nes intuitivas de fiabilidad y disponibilidad son a menudo mas amplias que estas definiciones 
limitadas. La definicion de fiabilidad establece que debe tenerse en cuenta el enlomo en el que 
el sistema se utiliza y el proposito para el que se utiliza. Si se mide la fiabilidad del sistema 
en un entorno, no se puede suponer que la fiabilidad sera la misma en otro entorno en el que 
el sistema se usa de forma diferente. 

Por ejemplo, consideremos que medimos la fiabilidad de un procesador de texto en un en- 
torno de oficina en el que la mayoria de los usuarios no estan interesados en como funciona. 
Ellos siguen las instrucciones para su uso y no tratan de experimentar con el sistema. Si se 
mide la fiabilidad del mismo sistema en un entorno universitario, entonces la fiabilidad pue- 
de serbastante diferente. Aqui, los estudiantes pueden explorar los limites del sistema y usar- 
lo de formas inesperadas. Esto puede producir fallos de funcionamiento en el sistema que no 
ocurririan en un entorno de oficina mas restringido. 

Las percepciones y patrones humanos de utilizacion tambien son significativos. Por ejem- 
plo, consideremos una situacion en la que el limpiaparabrisas de un automovil tiene un de- 
fecto, lo que hace que los limpiadores no funcionen correctamente bajo una tormenta. La fia- 
bilidad de este sistema percibidapor el conductor depende de donde viva este y el uso que se 
le de al automovil. Un conductor de Seattle (clima lluvioso) probablemente se vera mas afec- 
tado por este fallo que un conductor de Las Vegas (clima seco). La percepcion del conductor 
de Seattle sera que el sistema no es fiable, mientras que el conductor de Las Vegas puede que 
nunca se de cuenta del problema. 

Una dificultad adicional con estas definiciones es que no tienen en cuenta ni la gravedad 
de los fallos ni las consecuencias de la ausencia de disponibilidad. Las personas, natural- 
mente, se preocupan mas por los fallos del sistema que tienen consecuencias graves, y su 
percepcion de la fiabilidad se vera influenciada por dichas consecuencias. Por ejemplo, con- 
sideremos un fallo en el software que controla un motor de coche que hace que se cale in- 
mediatamente despues de encenderlo, pero dicho motor funciona correctamente despues de 
volver a arrancarlo, corrigiendo el problema de arranque. Esto no afecta al funcionamien- 
to normal del coche, y muchos conductores no pensaran en que es necesaria una reparacion. 
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Por el contrario, la mayoria de los conductores pensaran que un motor que se cale una vez 
al mes mientras esten conduciendo a alta velocidad (por ejemplo) no es fiable ni seguro y 
debe ser reparado. 

Unadefinicion estrictade fiabilidad relaciona la implementacion del sistemacon su espe- 
cificacion. Esto es, el sistema funciona de forma fiable si su comportamiento es consecuente 
con el definido en la especificacion. Sin embargo, una razon habitual por la que se advierte 
una falta de fiabilidad es que la especificacion del sistema no cumpla con las expectativas de 
los usuarios del sistema. Por desgracia, muchas especificaciones son incompletas o incorrec- 
tas, y se deja a los ingenieros de software que interpreten como deberia funcionarel sistema. 
Debido a que ellos no son expertos en el dominio, no pueden, por lo tanto, implementar el 
comportamiento que los usuarios esperan. 

La fiabilidad y la disponibilidad estan relacionadas con los fallos de funcionamiento del 
sistema. Estos pueden ser un fallo al proporcionar un servicio, un fallo provocado por la for- 
ma en que se proporciona dicho servicio, o la prestacion de un servicio de modo que este sea 
inseguro o no protegido. Algunos de estos fallos son consecuencia de errores de especifica- 
cion o fallos en sistemas asociados, como los sistemas de telecomunicaciones. Sin embargo, 
muchos fallos son consecuencia de comportamientos erroneos del sistema derivados de de- 
fectos existentes en este. Cuando se analiza la fiabilidad, es util distinguir entre los terminos 
defecto, errory fallo. Estos terminos se han definido en la Figura 3.5. 

Los errores humanos no conducen de forma inevitable a fallos de funcionamiento del sis- 
tema. Los defectos introducidos pueden estar en partes del sistema que nunca han sido usa- 
das. Los defectos no conducen necesariamente a errores del sistema, ya que el estado defec- 
tuoso puede ser transitorio y puede corregirse antes de que tenga lugar el comportamiento 
erroneo. Los errores del sistema pueden no provocar fallos de funcionamiento del sistema, ya 
que el comportamiento puede ser tambien transitorio y puede tener efectos inapreciables o el 
sistema puede incluir proteccion que asegure que el comportamiento erroneo sea descubier- 
to y corregido antes de que el funcionamiento del sistema se vea afectado. 

La diferencia entre los terminos mostrados en la Figura 3.5 nos ayuda a identificar tres en- 
foques complementarios usados para mejorar la fiabilidad de un sistema: 

1. Evitacion de defectos. Se utilizan tecnicas que minimizan la posibilidad de cometer 
equivocaciones y/o detectan las equivocaciones antes de que provoquen la introduc- 
cion de defectos en el sistema. Ejemplos de tales tecnicas son evitar el empelo de cons- 
trucciones de lenguajes de programacion propensas a errores, como los punteros, y el 
uso de analisis estatico para detectar anomalias en el programa. 





Fallo del sistema (en ingles, system failure) 


Everrto que tiene lugar en algun instarrte cuando el sistema no funciona como 
esperan sus usuarios. 


Error del sistema (en ingles, system error) 


Estado erroneo del sistema que puede dar lugar a un comportamiento del mis- 
mo inesperado por sus usuarios. 


Defecto del sistema (en ingles, system fault) 


Caracteristka de un sistema software que puede dar lugar a un error del siste- 
ma. Por ejemplo, un fallo en la efecudon al inidaJizar una variable puede hacer 
que dkha variable tenga un valor incorrecto cuando sea usada. 


Error htimano o equivocation 
(en ingles, mistake) 


Comportamiento humano que tiene como consecuencia la introduction de de- 
fectos en el sistema. 



Figura 3.5 Terminologfa de la fiabilidad. 
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2. Detection y elimination de defectos. Se usan tecnicas de verificacion y validacion que 
incrementan la posibilidad de que los defectos se detecten y eliminen antes de utilizar 
el sistema. Un ejemplo son las pruebas sistematicas del sistemay la depuracion. 

3. Tolerancia a defectos. Se usan tecnicas que aseguran que los defectos en un sistema 
no conducen a errores del sistema o que aseguran que los errores del sistema no dan 
lugara fallos de funcionamiento del sistema. Ejemplos de dichas tecnicas son la in- 
corporacion de facilidades de autodeteccion en un sistema y el uso de modulos re- 
dundantes del sistema. 

El desarrollo de sistemas tolerantes a defectos se trata en el Capitulo 20, en donde se ex- 
plican algunas tecnicas para prevencion de defectos. En el Capitulo 27 se estudian las apro- 
ximaciones basadas en procesos para la prevencion de defectos y la deteccion de defectos se 
trata en los Capitulos 22 y 23. 

Los defectos del software ocasionan fallos de funcionamiento del software cuando el co- 
digo con defectos se ejecuta con un conjunto de entradas que ponen de manifiesto los defec- 
tos del software. El codigo funciona correctamente para la mayoria de las entradas. La Figu- 
ra 3.6, obtenida de Littlewood (Liltlewood, 1990), muestra un sistema software como una 
correspondencia entre un conjunto de entradas y un conjunto de salidas. Dada una entrada o 
una secuencia de entradas, el programa responde produciendo la correspondiente salida. Por 
ejemplo, dada una entrada de una URL, un navegador web produce una salida que es la pan- 
talla de la pagina web solicitada. 

Algunas de estas combinaciones de entradas o salidas, mostradas en la elipse sombreada 
de la Figura 3.6, provocan la generacion de salidas erroneas. La (labilidad del software esta 
relacionada con la probabilidad de que, en una ejecucion particular del programa, la entrada 
del sistema pertenezca al conjunto de entradas que hacen que se produzca una salida erronea. 
Si una entrada que ocasiona una salida erronea se asocia con una parte del sistema que se usa 
con frecuencia, entonces los fallos de funcionamiento del sistema seran frecuentes. Sin em- 
bargo, si se asocia con codigo que se usa raramente, entonces los usuarios dificilmente veran 
los fallos de funcionamiento. 

Cada usuario de un sistema lo usa de diferentes formas. Los defectos que afectan a la 
fiabilidad del sistema para un usuario puede que nunca se manifiesten bajo otro modo de 
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trabajo (Figura 3.7). En la Figura 3.7, el conjunto de entradas erroneas se corresponden 
con la elipse sombreada de la Figura 3.6. El conjunto de entradas producido por el Usua- 
rio 2 se intersecta con este conjunto de entradas erroneas. El Usuario 2, por tanto, expe- 
rimentara algunos fallos de funcionamiento del sistema. El Usuario 1 y el Usuario 3, sin 
embargo, nunca usaran entradas del conjunto erroneo. Para ellos, el software siempre sera 
fiable. 

La fiabilidad de un programa, por lo tanto, depende principalmente del numero de en- 
tradas que provocan salidas erroneas durante el uso normal del sistema llevado a cabo por 
la mayoria de usuarios. Los defectos del software que se manifiestan solamente en situa- 
ciones excepcionales tienen poco efecto en la fiabilidad del sistema. La eliminacion de de- 
fectos del software en partes de un sistema que se utilizan raramente, hace que haya poca 
diferencia real con la fiabilidad percibida por los usuarios del sistema. Mills y otros (Mills 
el a/., 1987) senalan que la eliminacion del 60% de errores conocidos en su software per- 
mite una mejora de la fiabilidad solamente del 3%. Adams (Adams, 1984), en un estudio 
de productos software de I B M , observo que muchos defectos probablemente provocaran fa- 
llos de ejecucion despues de cientos o miles de meses de utilizarel producto. 

Los usuarios en un sistema socio-tecnico pueden adaptarse al software con defectos cono- 
cidos, y pueden compartir informacion acerca de como esquivar dichos problemas. Pueden 
evitar el uso de entradas que saben que produciran problemas, por lo que los fallos de fun- 
cionamiento nunca tendran lugar. Ademas, los usuarios experimentados suelen eludir los de- 
fectos del software que saben que provocaran fallos de funcionamiento. Evitan de forma de- 
liberada usar funcionalidades del sistema que saben que pueden causarles problemas. Por 
ejemplo, yo evito usarciertas funcionalidades, como lanumeracion automaticaconel proce- 
sador de textos que he usado para escribir este libro. La reparacion de defectos en estas fun- 
cionalidades puede no producir practicamente ninguna diferencia con la fiabilidad percibida 
por dichos usuarios. 



3.4 Seguridad 

Los sistemas de seguridad criticos son sistemas en los que es esencial que el funciona- 
miento del sistema sea siempre seguro. Esto es, el sistema nunca deberia provocar danos 
en las personas o en el entorno del sistema incluso si este falla. Ejemplos de sistemas de 
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seguridad criticos son el control y monitorizacion de sistemas de un avion, sistemas de 
control de procesos en plantas quimicas y farmaceuticas y sistemas de control de automo- 
viles. 

El control mediante hardware de los sistemas de seguridad criticos es mas sencillo de im- 
plementar y analizar que el control mediante software. Sin embargo, actualmente se estan 
construyendo sistemas de tal complejidad que no se pueden controlar unicamente mediante 
hardware. Es esencial realizar algun control mediante software debido a la necesidad de ges- 
tionar un numero muy grande de sensores y actuadores con leyes de control complejas. Un 
ejemplo que muestra dicha complejidad se encuentra en los aviones militares avanzados in- 
estables aerodinamicamente. Dichos sistemas requieren ajustes continuos, controlados por 
software, de sus superficies de vuelo para asegurar que no se estrellen. 

El software de seguridad critico se divide en dos clases: 

1. Software de seguridad critico primario. Es el software que esta embebido como un 
controlador en un sistema. El mal funcionamiento de dicho software puede ocasionar 
un mal funcionamiento del hardware, lo que puede provocar lesiones personales o da- 
iios en el entorno. Aqui nos centramos en este tipo de software. 

2. Software de seguridad critico secundario- Es el software que indirectamente puede 
provocar lesiones. Ejemplos de dichos sistemas son los sistemas de diseno asistido por 
computadora, cuyo mal funcionamiento podri a provocar un defecto de diseno en el ob- 
jeto que se esta disenando. Este defecto puede causar lesiones personales si el sistema 
disenado no funciona bien. Otro ejemplo de un sistema de seguridad critico secunda- 
rio es una base de datos medica que contiene los detalles de los medicamentos admi- 
nistrados a los pacientes. Los errores en este sistema podrian dar lugar a que se admi- 
nistrara una dosis de medicamentos incorrecta. 

La fiabilidad y la seguridad del sistema estan relacionadas, pero son distintos atributos de 
confiabilidad. Desde luego, un sistema de seguridad critico es fiable si esta de acuerdo con su 
especificacion y funciona sin fallos. Dicho sistema puede incorporarcaracteristicas de tole- 
rancia a defectos para que pueda proporcionar un servicio continuo incluso si se producen de- 
fectos. Sin embargo, los sistemas tolerantes a defectos no son necesariamente seguros. El soft- 
ware aun puede funcionar mal y ocasionar un comportamiento del sistema que provoque un 
accidente. 

Ademas del hecho de que nunca podemos tener la certeza absoluta de que un sistema soft- 
ware esta libre de defectos y es tolerante a fallos, hay muchas otras razones por las que un sis- 
tema software que es fiable no necesariamente es seguro: 

1. La especificacion puede estar incompleta en el sentido de que no describe el compor- 
tamiento requerido del sistema en algunas situaciones criticas. Un alto porcentaje de 
sistemas que funcionan mal (Natajo y Kume, 1991; Lutz, 1993) se debe a errores de 
especificacion mas que a errores de diseno. En un estudio de errores en sistemas em- 
potrados, Lutz concluye que: 

... las dificultades con los requerimientos son la causa clave de ; os errores de softwa- 
re relacionados con la seguridad que persistieron hasta la integration y /aprueba del 
sistema. 

2. El mal funcionamiento del hardware hace que el sistema se comporte de forma im- 
predecible y enfrente al software con un entorno inesperado. Cuando los componen- 
tes estan proximos a fallar, pueden comportarse de forma erratica y generar senales 
que estan fuera de los rangos que puede manejar el software. 
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3. Los operadores del sistema pueden generar entradas que no son individualmente in- 
correctas, pero que, en situaciones particulares, pueden dar lugar a un mal funciona- 
miento del sistema. Como ejemplo anecdotico se puede citar el caso en que un meca- 
nico dio instrucciones al software de utilidades de gestion de un avion para que 
levantarael trende aterrizaje. El software ejecuto las instrucciones perfectamente. Por 
desgracia, el avion permanecio en tierra todo el tiempo: claramente, el sistema debe- 
ria haber inhabilitado el comando a menos que el avion estuviese en el aire. 

Se ha creado un vocabulario especializado para tratar los sistemas de seguridad criticos y es 
importante comprender los terminos especificos utilizados. La Figura 3.8 recoge algunas defi- 
niciones que he adaptado de los terminos inicialmente definidos por Leveson (Leveson, 1985). 

La clave para garantizar la seguridad es asegurar que los accidentes no ocurran o que las con- 
secuencias de estos sean minimas. Esto puede conseguirse de tres formas complementarias: 

1 . Evitacion de contingencias. El sistema se disena para que las contingencias se eviten. 
Por ejemplo, un sistema de corte que requiere que el operador presione dos botones 
distintos a! mismo tiempo parautilizar la maquina evita lacontingenciade que los de- 
dos del operador esten cerca de las cuchillas. 

2. Detection y elimination de contingencias. El sistema se disena para que las contin- 
gencias se detecten y eliminen antes de que provoquen un accidente. Por ejemplo, un 
sistema de una planta quimica puede detectar una presion excesiva y abrir una valvu- 
la de escape para reducir la presion antes de que ocurra una explosion. 

3. Limitation de dahos. El sistema incluye caracteristicas de proteccion que minimizan 
el dano que puede resultar de un accidente. Por ejemplo, el motor de un avion nor- 
malmente incluye extintores de incendios automaticos. Si se produce un fuego, a me- 
nudo este se puede controlar antes de que suponga una amenaza para el avion. 

Los accidentes ocurren generalmente cuando varias cosas van mal al mismo tiempo. Un 
analisis de accidentes serios (Perrow, 1984) sugiere que casi todos ellos se debieron a una 





Accidente (o percance) 


Evento o secuenda de event os no planrficados que provocan muerte o lesiones, dano a las 
prop red ades o al entomo. Un ejemplo de un accidente es una maquina controlada por un 
oidenador que lesiona a su operador. 


Contingency 


Una condicidn con el potencial de causar o contribuir a un accidente. Un ejemplo de con- 
tingenda es un fallo de funckmamiento de un sensor que detecta un obst&culo delante de 
una maquina. 


Daho 


Medkla de la perdida resultant* de un percance. El dafto puede variar desde varias personas 
muertas como resukado de un accidente, hosts lesiones o danos menores a la propiedad. 


Gravedad de la contingenda 


Evaluation del peor dafio posiMe que podrta resurtar de una contingency en particular. La 
gravedad de la contingenda puede variar desde catastrofica, en donde mudias personas 
mueren, a menor, en donde resultan solamente daflos menores. 


Probabilidad de la contingenda 


La probabilidad de la ocurrenda de eventos que provocan una contingenda. Los valores de 
probabilidad tienden a ser arbitrarios. pero varfan desde probable (por ejemplo. una proba- 
bi&dad de ocurrencia del 1/100) hasta improbable (situaciones no concebibles en las que 
probablemente ocurra la contingenda). 


Riesgo 


Es una medida de la probabilidad de que el sistema provoque un accidente. El riesgo se eva- 
lua considerando la probabilidad de la contingenda, la gravedad de la contingenda y la pro- 
babilidad de que una contingenda cause un acddente. 

Figura 3.8 Terminologia sobre seguridad. 
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combinacion de malos funcionamientos mas que a fallos aislados. Lacombinacion no antici- 
pada condujo a interacciones que provocaron fallos de funcionamiento del sistema. Perrow 
sugiere tambien que es imposible anticiparse a todas las posibles combinaciones de mal fun- 
cionamiento de un sistema, y que los accidentes son una parte inevitable del uso de sistemas 
complejos. El software tiende a incrementar la complejidad del sistema, de forma que reali- 
zar el control mediante software puede incrementar la probabilidad de accidentes del sistema. 

Sin embargo, el software de control y monitorizacion puede mejorar tambien la seguridad 
de los sistemas. Los sistemas controlados por software pueden monitorizar un rango de con- 
diciones mas amplio que los sistemas electromecanicos. Los primeros se pueden adaptarcon 
relativa facilidad. Ademas implican el uso del hardware de la computadora, el cual tiene una 
fiabilidad inherente muy altay es fisicamentepequeflo y ligero. Los sistemas controlados por 
software pueden proporcionar mecanismos de seguridad sofisticados. Pueden soportar estra- 
tegias de control que reducen la cantidad de tiempo que las personas necesitan consumir en 
entornos con contingencias. En consecuencia, si bien el software de control puede introducir 
mas formas en las que un sistema puede funcionar mal, tambien permite una mejor monito- 
rizacion y proteccion y, por lo tanto, puede mejorar la seguridad del sistema. 

En todos los casos, es importante mantenerun sentido de la proporcion sobre la seguridad 
del sistema. Es imposible conseguir que un sistema sea totalmente seguro, y la sociedad debe 
decidir si los beneficios del uso de tecnologias avanzadas compensan o no las consecuencias 
de un accidente ocasional. Tambien es una decision social y politica como utilizarunos re- 
cursos nacionales limitados a fin de reducir el riesgo para la poblacion en su conjunto. 

Proteccion 

La proteccion es un atributo del sistema que refleja su capacidad para protegerse de ataques 
externos que pueden ser accidentales o provocados. La proteccion ha adquirido cada vez mas 
importancia en tanto que mas y mas sistemas se han conectado a Internet. Las conexiones a 
Internet proporcionan funcionalidades del sistema adicionales (por ejemplo, los clientes pue- 
den acceder directamente a sus cuentas bancarias), pero la conexion a Internet tambien sig- 
nifica que el sistema puede ser atacado por personas con intenciones hostiles. La conexion a 
Internet tambien conlleva que los detalles sobre vulnerabilidades particulares del sistema 
pueden difundirse facilmente para que mas personas sean capaces de atacar al sistema. Del 
mismo modo, sin embargo, la conexion puede acelerar la distribucion de parches del sistema 
para reparar estas vulnerabilidades. 

Ejemplos de ataques podrian ser los virus, el uso no autorizado de servicios del sistema y la 
modificacion no autorizada del sistema o sus datos. La proteccion es importante para todos los 
sistemas criticos. Sin un nivel razonable de proteccion, la disponibilidad, fiabilidad y seguridad 
del sistema pueden verse comprometidas si ataques externos provocan danos al mismo. 

La razon de esto es que todos los metodos para asegurar la disponibilidad, fiabilidad y se- 
guridad se valen del hecho de que el sistema operacional es el mismo que se instalo original- 
mente. Si dicho sistema instalado se ha visto comprometido de alguna forma (por ejemplo, si 
el software se ha modificado para aceptar un virus), entonces los argumentos para la fiabili- 
dad y la seguridad originalmente establecidos dejan de serciertos. El sistema de software pue- 
de entonces corromperse y comportarse de forma impredecible. 

Por el contrario, los errores en el desarrollo de un sistema pueden provocar agujeros de protec- 
cion. Si un sistema no responde a entradas inesperadas o si los limites de un vector no se verifican, 
entonces los atacantes pueden explotar estas debilidades para tener acceso al sistema. Los inci- 
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dentes de proteccion mas importantes tales como el gusano de Internet original (Spafford, 1989) y 
el gusano Code Red mas de diez aflos despues (Berghel, 200 1) se aprovecharon del hecho de que 
los programas en C no incluyen verificacion de los Hmites de los vectores. Los gusanos sobrescri- 
bieron parte de la memoria con codigo que permitio el acceso no autorizado al sistema. 

Por supuesto, en algunos sistemas criticos, la proteccion es la dimension mas importante de 
la confiabilidad del sistema. Los sistemas militares, los sistemas de comercio electronico y los 
sistemas que implican el procesamiento e intercambio de informacion confidencial, se deben di- 
senar de tal forma que alcancen altos niveles de proteccion. Si un sistema de reservas de billetes 
de avion (por ejemplo) no esta disponible, esto provoca inconvenientes y algunos retrasos en la 
emision de los billetes. Sin embargo, si el sistema no esta protegido y puede aceptar reservas fal- 
sas, entonces la linea aerea propietaria del sistema puede perder una gran cantidad de dinero. 

Existen tres tipos de danos que pueden ser causados por ataques externos: 

1. Denegacion de servicio. El sistema puede verse forzado a entrar en un estado en que 
sus servicios normales no estan disponibles. Esto, obviamente, afecta a la disponibi- 
lidad del sistema. 

2. Corruption de programas o daros. Los componentes software del sistema pueden ser 
alterados de forma no autorizada. Esto puede afectar al comportamiento del sistema 
y, por lo tanto, a su fiabilidad y a su seguridad. Si el dano es grave, la disponibilidad 
del sistema puede verse afectada. 

3 . Revelation de information confidential. La informacion gestionada por el sistema pue- 
de ser confidencial y los ataques externos pueden exponerla a personas no autorizadas. 
Dependiendo del tipo de datos, esto podria afectar a la seguridad del sistema y puede 
permitir ataques posteriores que afecten a la disponibilidad o fiabilidad del sistema. 

Como con otros aspectos de la confiabilidad, existe una terminologia especializada aso- 
ciadacon la proteccion. Algunos terminos importantes, como los tratados por Pfleeger (1977), 
se definen en la Figura 3.9. 

Existe una clara analogia con cierta terminologia de la seguridad en el sentido de que una ex- 
posiciones analogaaun accidente y unavulnerabilidad es analogaaunacontingencia. Por tanto, 
existen aproximaciones comparables que se utilizan para garantizar la proteccion de un sistema: 

1 . Evitar la vulnerabilidad. El sistema se disefia para que las vulnerabilidades no ocu- 
rran. Por ejemplo, si un sistema no esta conectado a una red publica externa, entonces 
no existe la posibilidad de un ataque por parte de otras personas conectadas a la red. 
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Figura 3.9 Terminologia sobre protecci6n. 
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2. Defection y neutralization de ataques. El sistema se disena para detectar vulnerabili- 
dades y eliminarlas antes de que provoquen una exposicion del sistema. Un ejemplo 
de deteccion y eliminacion de la vulnerabilidad es la utilizacion de un verificador de 
virus que analiza los flcheros entrantes y los modifica para eliminar el virus. 

3. Limitation de la exposition. Las consecuencias de un ataque exitoso se minimizan. 
Ejemplos de limitacion de la exposicion son los sistemas de copias de seguridad pe- 
riodicas y una politica de gestion de configuraciones que permite que el software da- 
nado pueda reconstruirse. 

La gran mayoria de las vulnerabilidades en los sistemas informaticos se originan en fallos 
humanos en lugar de en problemas tecnicos. Las personas eligen palabras clave faciles de re- 
cordar o las escriben en lugares en donde resulta facil encontrarlas. Los administradores del 
sistema cometen errores en la actualizacion del control de acceso o de flcheros de configura- 
cion y los usuarios olvidan instalar o usar software de proteccion. Paramejorar la proteccion, 
por lo tanto, necesitamos adoptar una perspectiva socio-tecnica y pensar en como se usan re- 
almente los sistemas y no solamente en sus caracteristicas tecnicas. 



PUNTOS CLAVE 

• En un sistema criti co, un fallo de funcionamiento puede provocarperdidaseco no micas importantes, danosfi- 
sicos o amenazas a ta vida humana. Tres clases importantes de sistemas criticos son los sistemas de seguri- 
dad criticos, sistemas de mision criticos y sistemas de negocio criticos. 

• Laconfiabilidaddeun sistema informaticoes una propiedad del sistema que refleja el grado de confianza que 
elusuariotieneenel sistema. Las dimensiones mas importantes de la confiabilidad son tadisponibilidad,fia- 
bilidad, seguridad y proteccion. 

• La disponibilidad de un sistema es la probabilidad de que le sea posible entregar los servicios a sus usuarios 
cuando se lo soliciten y la fiabilidad es la probabilidad de que los servicios del sistema se entreguen de acuer- 
do con lo especificado. 

• La fiabilidad y ta disponibilidad se consideran normalmente como las dimensiones mas importantes de ta con- 
fiabilidad. Si un sistema no es fiable, es dif fell asegurar la seguridad del sistema osu proteccion, ya que es- 
tas pueden verse comprometidas por fallos de funcionamiento del sistema. 

• La fiabilidad se relaciona con ta probabilidad de que se produzca un erroren el momento de utilizarel siste- 
ma. Un programa puede contener defectos conocidos, pero aun puede considerarse como fiable por sus usua- 
rios. Estos pueden no usar nunca las caracteristicas del sistema que estan afectadas poresosdefectos. 

• La seguridad de un sistema es un atributo de este que refleja la capacidad del sistema para funcionar, de for- 
ma normal o anormalmente, sin amenazara las personas o al entorno. 

• La proteccion es importante para todos los sistemas criticos. Sin un nivel de proteccion razonable, la dispo- 
nibilidad, fiabilidad y seguridad de un sistema pueden verse comprometidas si ataques externos provocan al- 
gun dano al sistema. 

• Para mejorar la confiabilidad, es necesario adoptar una a proxi maclon socio-tecnica para el d i sen o del siste- 
ma, teniendo en cuenta a las personas que forman parte del sistema asi como el hardware y el software. 
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LECTURAS ADICIONALES 



«The evolution of information assurance». Un articulo excelente que trata la necesidad de proteger la informacion 
critica de accidentes y ataques en una organizacion. [R. Cummings, IEEE Computer, 35 (12), diciembre de 2002.] 

Practical Design of Safety-critical Computer Systems. Una revision general del disefio de sistemas de seguridad cri- 
ticos que trata cuestiones de seguridad y que considera el concepto de sistemas y no simplemente una perspecti- 
va software. (W. R. Dunn, Reliability Press, 2002.) 

Secrets and ties: Digital Security in a Networked World. Un libra excelente y muy legible sobre proteccion de com- 
putadoras desde un punto de vista socio-tecnico. (B. Schneier, 2000, John Wiley & Sons.) 

«Survivability: Protecting your critical systems». Unaintroduccion accesibleal temade supervivenciay elporque 
de su importancia. (R. Ellison etai, IEEE Internet Computing, noviembre-diciembre de 1999.) 

Computer-related Risks. Una coleccion extraida del Internet Risks Forum sobre los incidentes ocurridos en sistemas 
automatizados. Muestra lo que puede ir mal realmente en relacion con la seguridad de sistemas. (P. G. Neumann, 
1 995» Addison- Wesley.) 



EJERCICIOS 



3.1 ^Cuales son los tres tipos principales de sistemas criticos? Explique las diferencias entre ellos. 
32 Sugiera seis razones de por que la confiabilidad es importante en sistemas criticos. 

3.3 ^Cuales son las dimensiones mas importantes de ta confiabilidad del sistema? 

3.4 (,P° r qus el coste para garantizar la confiabilidad es exponencial? 

3.5 Sugiera, justificando sus respuestas, por que los atributos de confiabilidad son probablemente los mas cri- 
ticos para los sistemas siguientes: 

• Un servidor de Internet proporcionado por un ISP con miles de clientes. 

• Un escalpelo controlado por computadora usado para practicar incisiones en operaciones quirurgicas. 

• Un sistema de control direccional usado en el lanzamiento de un vehiculo espacial. 

• Un sistema de gestion de finanzas personales a traves de Internet. 

3.6 Identifique seis productos de consumo que contengan, o que puedan contener en el futuro, sistemas soft- 
ware de seguridad criticos. 

3.7 Lafiabilidady la seguridad son atributos de confiabilidad re lacionados pero distintos. Describaladistincion 
mas importante entre estos atributos y explique por que es posible para un sistema fiable ser inseguro y vi- 
ceversa. 

3.8 En un sistema medico disefiado para suministrar radiacion para tratar tumores, sugiera una contingencia 
que pueda ocurrir y proponga una caracteristica del software que pueda usarse para asegurar que la con- 
tingencia identificada no derive en un accidente. 

3.9 Explique por que hay una estrecha relacion entre disponibilidad del sistema y proteccion del sistema. 
3.10 En terminos de proteccion de computadoras, explique las diferencias entre un ataque y una amenaza. 
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^Es etico para un ingeniero estar de acuerdo en entregar a un cliente un sistema software con defectos co- 
nocidos? ^Hay alguna diferencia si al cliente se le informa de la existencia de estos defectos con antelacion? 
^Podria ser razonable realizar afirmaciones sobre la fiabilidad del software en dichas circunstancias? 

Como experto en proteccion de computadoras, suponga que una organizacion que realiza una campafia 
por los derechos de las victimas de torturas le pide que ayude a la organizacion a conseguir accesos no 
autorizados a los sistemas informaticos de una compafiia americana. Esto les ayudaria a confirmaro des- 
mentirque esta compania esta vendiendo equipamiento que se usa directamente en la tortura de prisio- 
neros politicos. Comente los problemas eticos que esta solicitud provocay como podria reaccionar ante 
estapeticion. 



Procesos 
del software 



Objetivos 

El objetivo de este capitulo es introducirlo al concepto del proceso 
del software — un conjunto coherente de actividades para la 
produccion de software — . Cuando haya leido este capitulo: 

• entendera el concepto de procesos del software y los modelos 
de estos procesos; 

• entendera tres modelos del proceso del software genericos y 
cuando deben utilizarse; 

• entendera, a grandes rasgos, las actividades relacionadas en 
la ingenieria de requerimientos del software, desarrollo de 
software, pruebas y evolucion; 

• entendera como el Proceso Unificado de Rational integra 
buenas practicas del proceso del software para crear un 
modelo del proceso moderno y generico; 

• habra sido introducido a la tecnologia CASE que se utiliza 
para ayudar a las actividades del proceso del software. 

Contenidos 

4.1 Modelos del proceso del software 

4.2 Iteracion de procesos 

4.3 Actividades del proceso 

4.4 El Proceso Unificado de Rational 

4.5 Ingenieria del software asistidaporcomputadora 
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Un proceso del software es un conjunto de actividades que conducen a la creacion de un pro- 
ducto software. Estas actividades pueden consistir en el desarrollo de software desde cero 
en un lenguaje de programacion estandar como Java o C. Sin embargo, cada vez mas, se 
desarrolla nuevo software ampliando y modificando los sistemas existentes y configurando 
e integrando software comercial o componentes del sistema. 

Los procesos del software son complejos y, como todos los procesos intelectuales_y crea- 
tivos, dependen de las personas que toman decisiones y juicios. Debido a la necesidad de juz- 
gar y crear, los intentos para automatizar estos procesos han tenido un exito limitado. Las he- 
rramientas de ingenieria del software asistida por computadora (CASE) (comentadas en la 
Seccion 4.5) pueden ayudar a algunas actividades del proceso. Sin embargo, no existe posi- 
bilidad alguna, al menos en los proximos anos, de una automatizacion mayor en el diseno cre- 
ativo del software realizado por los ingenieros relacionados con el proceso del software. 

Una razon por la cual la eficacia de las herramientas CASE esta limitada se halla en la inmen- 
sa diversidad de procesos del software. No existe un proceso ideal, y muchas organizaciones han 
desarrollado su propio enfoque para el desarrollo del software. Los procesos han evolucionado 
para explotar las capacidades de las personas de una organizacion, asi como las caracteristicas es- 
pecificas de los sistemas que se estan desarrollando. Para algunos sistemas, como los sistemas cri- 
ticos, se requiere un proceso de desarrollo muy estructurado. Para sistemas de negocio, con re- 
querimientos rapidamente cambiantes, un proceso flexible y agil probablemente sea mas efectivo. 

Aunque existen muchos procesos diferentes de software, algunas actividades fundamen- 
tales son comunes para todos ellos: 

1. Especijicacion del software. Se debe definir la funcionalidad del software y las res- 
tricciones en su operacion. 

2. Diseno e implementation del software. Se debe producir software que cumpla su es- 
pecificacion. 

3. Validation del software. Se debe validar el software para asegurar que hace lo que el 
cliente desea. 

4. Evolution del software. E 1 software debe evolucionar para cubrir las necesidades cam- 
biantes del cliente. 

En este capitulo se tratan brevemente estas actividades y se analizan con mas detalle en par- 
tes posteriores del libro. 

Aunque no existe un proceso del software «ideal», en las organizaciones existen enfoques 
para mejorarlos. Los procesos pueden incluirtecnicas anticuadas o no aprovecharse de las me- 
jores practicas en la ingenieria del software industrial. De hecho, muchas organizaciones aun 
no aprovechan los metodos de la ingenieria del software en el desarrollo de su software. 
( Los procesos del software se pueden mejorarpor la estandarizacion del proceso donde la 
diversidad de los procesos del software en una organizacion sea reducida. Esto conduce a me- 
jorar lacomunicacion y aunareduccion del tiempo de formacion, y hace laayuda al proceso 
automatizado mas economica A La estandarizacion tambien es un primer paso importante para 
introducir nuevos metodos, tecnicas y buenas practicas de ingenieria del software. En el Ca- 
pitulo 28 se trata con mas detalle la mejora del proceso del software. 

4.1 Modelos del proceso del software 

Como se explico en el Capitulo 1, un modelo del proceso del software es una representa- 
cion abstracta de un proceso del software. Cada modelo de proceso representa un proceso 
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desde una perspectiva particular, y asi proporciona solo informacion parcial sobre ese pro- 
ceso. En esta seccion, se introducen varios modelos de proceso muy generales (algunas ve- 
ces Wamados paradigmas de proceso) y se presentan desde una perspectiva arquitectoni- 
ca. Esto es, vemos el marco de trabajo del proceso, pero no los detalles de actividades 
especificas. 

Estos modelos generales no son descripciones definitivas de los procesos del software. Mas 
bien, son abstracciones de los procesos que se pueden utilizar para explicar diferentes enfo- 
ques para el desarrollo de software. Puede pensarse en ellos como marcos de trabajo del pro- 
ceso que pueden ser extendidos y adaptados para crear procesos mas especificos de ingenie- 
ria del software. 

Los modelos de procesos que se incluyen en este capitulo son: 

1 . El modelo en cascada. Considera las actividades fundamentales del proceso de espe- 
cificacion, desarrollo, validacion y evolucion, y los representa como fases separadas 
del proceso, tales como la especificacion de requerimientos, el disenodel software, la 
implementacion, las pruebas, etcetera. 

2. Desarrollo evolutivo. Este enfoque entrelaza las actividades de especificacion, desa- 
rrollo y validacion. Un sistema inicial se desarrolla rapidamente a partir de especifi- 
caciones abstractas. Este se refina basandose en las peticiones del cliente para produ- 
cir un sistema que satisfaga sus necesidades. 

3. Ingenieria del software basada en componentes. Este enfoque se basa en la existencia 
de un numero significativo de componentes reutilizables. El proceso de desarrollo del 
sistema se enfoca en integrar estos componentes en el sistema mas que en desarro- 
llarlos desde cero. 

Estos tres modelos de procesos genericos se utilizan ampliamente en la practica actual de 
la ingenieria del software. No se excluyen mutuamente y a menudo se utilizan juntos, espe- 
cialmente para el desarrollo de sistemas grandes. De hecho, el Proceso Unificado de Rational 
que se trata en la Seccion 4.4 combina elementos de todos estos modelos. Los subsistemas 
deniro de un sistema mas grande pueden ser desarrollados utilizando enfoques diferentes. Por 
lo tanto, aunque es conveniente estudiar estos modelos separadamente, debe entenderse que, 
en la practica, a menudo se combinan. 

Se han propuesto todo tipo de variantes de estos procesos genericos y pueden ser usados 
en algunas organizaciones. La variante mas importante es probablemente el desarrollo formal 
de sistemas, donde se crea un modelo formal matematico de un sistema. Este modelo se 
transforma entonces, usando transformaciones matematicas que preservan su consistencia, en 
codigo ejecutable. 

El ejemplo mas conocido de un proceso de desarrollo formal es el proceso de sala limpia, 
el cual fue originalmente desarrollado por IBM (Mills etal., 1987; Selby etai, 1987; Linger. 
1994: Prowell etal., 1999). En el proceso de sala limpia, cada incremento del software se es- 
pecifica formalmente, y esta especificacion se transforma en una implementacion. La correc- 
cion del software se demuestra utilizando un enfoque formal. No hay pruebas para defectos 
en el proceso, y las pruebas del sistema se centran en evaluar su fiabilidad. 

Tanto el enfoque de sala limpia como otro enfoque para desarrollo formal basado en el me - 
todo B (Wordsworth, 1996) son particularmente apropiados para el desarrollo de sistemas que 
tienen estrictos requerimientos de seguridad, fiabilidad o proteccion. El enfoque formal sim- 
plifica la produccion de un caso de seguridad o proteccion que demuestre a los clientes u or- 
ganismos de certificacion que el sistema realmente cumple los requerimientos de seguridad y 
proteccion. 
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Procesos del software 



Fuera de estos ambitos especializados, los procesos basados en transformaciones forma - 
les no se utilizan en general. Requieren una pericia especializada y, en realidad, para la ma- 
yoria de los sistemas este proceso no offece ventajas importantes de coste o calidad sobre otros 
enfoques para el desarrollo de sistemas. 



El primer modelo de proceso de desarrollo de software que se publico se derivo de procesos 
de ingenieria de sistemas mas generales (Royce, 1970). Este modelo se muestra en la Figura 
4. 1 . Debido a la cascada de una fase a otra, dicho modelo se conoce como modelo en casca- 
da o como ciclo de vida del software. Las principales etapas de este modelo se transforman 
en actividades fundamentales de desarrollo: 

1. Analisisy definition de requerimientos. Los servicios, restricciones y metas del siste- 
ma se definen a partir de las consultas con los usuarios. Entonces, se definen en deta- 
lle y sirven como una especificacion del sistema. 

2. Diseho delsistemay del software. E 1 proceso de disefio del sistema divide los reque- 
rimientos en sistemas hardware o software. Establece una arquitectura completa del 
sistema. El disefio del software identifica y describe las abstracciones fundamentales 
del sistema software y sus relaciones. 

3. implementation y prueba de unidades. Durante esta etapa, el disefio del software se 
lleva a cabo como un conjunto o unidades de programas. La prueba de unidades im- 
plica verificar que cada una cumpla su especificacion. 

4. Integration y prueba del sistema. Los programas o las unidades individuales de pro- 
gramas se integran y prueban como un sistema completo para asegurar que se cum- 
plan los requerimientos del software. Despues de las pruebas, el sistema software se 
entrega al cliente. 

5. Funcionamiento y mantenimiento. Por lo general (aunque no necesariamente), esta es 
la fase mas larga del ciclo de vida. El sistema se instala y se pone en funcionamiento 
practico. El mantenimiento implica corregir errores no descubiertos en las etapas an- 
terioresdel ciclo de vida, mejorarla jmplementacionde las unidades del sistema y re- 
saltar los servicios del sistema una vez que se descubren nuevos requerimientos. 
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En principio, el resultado de cada fase es uno o mas documentos aprobados («firmados»). 
La siguiente fase no debe empezarhasta que la fase previa haya finalizado. En lapractica, es- 
tas etapas se superponen y proporcionan informacion a las otras. Durante el diseno se identi- 
fican los problemas con los requerimientos; durante el diseno del codigo se encuentran pro- 
blemas, y asi sucesivamente. El proceso del software no es un modelo lineal simple, sino que 
implica una serie de iteraciones de las actividades de desarrollo. 

Debido a los costos de produccion y aprobacion de documentos, las iteraciones son cos- 
tosas e implican rehacer el trabajo. Por lo tanto, despues de un numero reducido de iteracio- 
nes, es normal congelar partes del desarrollo, como la especificacion, y continuar con las si- 
guientes etapas de desarrollo. Losproblemas seposponen parasuresolucion, sepasan por alto 
o se programan. Este congelamiento prematuro de requerimientos puede implicar que el sis- 
tema no haga lo que los usuarios desean. Tambien puede conducir a sistemas mal estructura- 
dos debido a que los problemas de diseno se resuelven mediante trucos de implementacion. 

Durante la fase final del ciclo de vida (funcionamiento y mantenimiento), el software se 
pone en funcionamiento. Se descubren errores y omisiones en los requerimientos originales del 
software. Los errores deprogramaciony de diseno emergen y se identificalanecesidaddeuna 
nueva funcionalidad. Por tanto, el sistema debe evolucionar para mantenerse util. Hacer estos 
cambios (mantenimiento del software) puede implicar repetir etapas previas del proceso. 

Las ventajas del modelo en cascada son que la documentacion se produce en cada fase y 
que este cuadra con otros modelos del proceso de ingenieria. Su principal problema es su in- 
flexibilidad al dividir el proyecto en distintas etapas. Se deben hacer compromisos en las eta- 
pas iniciales, lo que hace dificil responder a los cambios en los requerimientos del cliente. 

Por lo tanto, el modelo en cascada solo se debe utilizarcuando los requerimientos se com- 
prendan bien y sea improbable que cambien radicalmente durante el desarrollo del sistema. 
Sin embargo, el modelo refleja el tipo de modelo de proceso usado en otros proyectos de la 
ingenieria. Porconsiguiente, los procesos del software que se basan en este enfoque se siguen 
utilizando para el desarrollo de software, particularmente cuando este es parte de proyectos 
grandes de ingenieria de sistemas. 



4.1.2 Desarrollo evolutivo 

El desarrollo evolutivo se basa en la ideade desarrollaruna implementacion inicial, expo- 
niendola a los comentarios del usuario y refinandolaa traves de las diferentes versiones has- 
la que se desarrolla un sistema adecuado (Figura 4.2). Las actividades de especificacion, 
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desarrollo y validacion se entrelazan en vez de separarse, con una rapida retroalimentacion 
entre estas. 

Existen dos tipos de desarrollo evolutivo: 

1 . Desarrollo exploratorio, donde el objetivo del proceso es trabajar con el cliente para 
explorar sus requerimientos y entregarun sistema final. El desarrollo empieza con las 
partes del sistema que se comprenden mejor. El sistema evoluciona agregando nuevos 
atributos propuestos por el cliente. 

2. Prototipos desechadles, donde el objetivo del proceso de desarrollo evolutivo es com- 
prender los requerimientos del cliente y entonces desarrollar una definicion mejorada 
de los requerimientos para el sistema. El prototipo se centra en experimentar con los A 
requerimientos del cliente que no se comprenden del todo. 

En la produccion de sistemas, un enfoque evolutivo para el desarrollo de software suele ser 
mas efectivo que el enfoque en cascada, ya que satisface las necesidades inmediatas de los 
clientes. La ventaja de un proceso del software que se basa en un enfoque evolutivo es que la 
especificacion se puede desarrollar de forma creciente. Tan pronto como los usuarios des- 
arrollen un mejor entendimiento de su problema, este se puede reflejar en el sistema softwa- 
re. Sin embargo, desde una perspectiva de ingenieria y de gestion, el enfoque evolutivo tiene 
dos problemas: 

1 . El proceso no es visible. Los administradores tienen que hacer entregas regulares para 
medirel progreso. Si los sistemas se desarrollan rapidamente, no es rentable producir 
documentos que reflejen cada version del sistema. 

2. ,4 menudo los sistemas tienen una estructura deflciente. Los cambios continuos tien- 
den a corromper la estructura del software. Incorporar cambios en el se convierte cada 
vez mas en una tarea dificil y costosa. 

Para sistemas pequenos y de tamano medio (hasta 500.000 lineas de codigo), el enfoque evo- 
lutivo de desarrollo es el mejor. Los problemas del desarrollo evolutivo se hacen particularmen- 
te agudos para sistemas grandes y complejos con un periodo de vida largo, donde diferentes equi- 
pos desarrollan distintas partes del sistema. Es dificil establecer una arquitectura del sistema 
estable usando este enfoque, el cual hace dificil integrar las contribuciones de los equipos. 

Para sistemas grandes, se recomienda un proceso mixto que incorpore las mejores carac- 
teristicas del modelo en cascada y del desarrollo evolutivo. Esto puede implicar desarrollar 
un prototipo desechable utilizando un enfoque evolutivo para resolver incertidumbres en la es- 
pecificacion del sistema. Puede entonces reimplementarse utilizando un enfoque mas estruc- 
turado. Las partes del sistema bien comprendidas se pueden especificar y desarrollar utili- 
zando un proceso basado en el modelo en cascada. Las otras partes del sistema, como la 
interfaz de usuario, que son dificiles de especificar por adelantado, se deben desarrollar siem- 
pre utilizando un enfoque de programacion exploratoria. 

Los procesos del desarrollo evolutivo y el proceso de apoyo se estudian con mas detalle en 
el Capitulo 17, junto con la construccion de prototipos de sistemas y el desarrollo rapido de 
aplicaciones. El desarrollo evolutivo tambien se incorpora en el Proceso Unificado de Ratio- 
nal que se trata mas tarde en este capitulo. 

4.1.3 Ingenieria del software basada en componentes 

En la mayoria de los proyectos de software existe algo de reutilizacion de software. Por lo ge- 
neral, esto sucede informalmente cuando las personas que trabajan en el proyecto conocen di- 
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senos o codigo similares al requerido. Los buscan, los modifican segun lo creen necesario y 
los incorporan en el sistema. En el enfoque evolutivo, descrito en la Seccion 4. 1 .2, la reutili- 
zacion es a menudo indispensable para el desarrollo rapido de sistemas. 

Esta reutilizacion informal es independiente del proceso de desarrollo que se utilice. Sin 
embargo, en los ultimos anos, ha surgido un enfoque de desarrollo de software denominado 
ingenieria del software basada en componentes (CB SE) que se basa en la reutilizacion, el cual 
se esta utilizando de forma amplia. Se introduce brevemente este enfoque aqui, pero se estu- 
dia con mas detalle en el Capitulo 19. 

Este enfoque basado en la reutilizacion se compone de una gran base de componentes soft- 
ware reutilizablesy de algunos marcos de trabajo de integracionparaestos. Algunas veces es- 
tos componentes son sistemas por si mismos (COTS o sistemas comerciales) que se pueden 
utilizar para proporcionar una funcionalidad especifica, como dar formato al texto o efectuar 
calculos numericos. En laFigura4.3 se muestra el modelo del proceso generico para la CBSE . 

Aunque la etapa de especificacion de requerimientos y la de validacion son comparables 
con otros procesos, las etapas intermedias en el proceso orientado a la reutilizacion son dife- 
rentes. Estas etapas son: 

1. Andlisis de componentes. Dada la especificacion de requerimientos, se buscan los 
componentes para implementar esta especificacion. Por lo general, no existe una con- 
cordancia exacta y los componentes que se utilizan solo proporcionan parte de la fun- 
cionalidad requerida. 

2. Modification de requerimientos. En esta etapa, los requerimientos se analizan utili- 
zando informacion acerca de los componentes que se han descubierto. Entonces, es- 
tos componentes se modifican para reflejar los componentes disponibles. Si las mo- 
dificaciones no son posibles, la actividad de analisis de componentes se puede llevar 
a cabo nuevamente para buscar soluciones alternativas. 

3. Diseito del sistema con reutilizacion. En esta fase se disefia o se reutiliza un marco de 
trabajo para el sistema. Los disenadores tienen en cuenta los componentes que se reu- 
tilizan y organizan el marco de trabajo para que los satisfaga. Si los componentes 
reutilizables no estan disponibles, se puede tener que disenar nuevo software. 

4. Desarrollo e integration. Para crear el sistema, el software que no se puede adquirir 
externamente se desarrolla, y los componentes y los sistemas COTS se integran. En 
este modelo, la integracion de sistemas es parte del proceso de desarrollo, mas que una 
actividad separada. 

La ingenieria del software basada en componentes tiene la ventaja obvia de reducir la can- 
tidad de software a desarrollarse y asi reduce los costos y los riesgos. Por lo general, tambien 
permite una entrega mas rapida del software. Sin embargo, los compromisos en los requeri- 
mientos son inevitables, y esto puede dar lugar a un sistema que no cumpla las necesidades 
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reales de los usuarios. Mas aun: si las nuevas versiones de los componentes reutitizables no 
estanbajo el control de laorganizacionque losutiliza, se pierde parte del control sobre laevo- 
lucion del sistema. 

La CB SE tiene mucho en comun con un enfoque que esta surgiendo para el desarrollo de 
sistemas que se basa en la integracion de servicios web de una serie de proveedores. En el Ca- 
pitulo 12 se describe este enfoque de desarrollo de servicio centrico. 

4.2 Iteracion de procesos 

Los cambios son inevitables en todos los proyectos de software grandes. Los requerimientos 
del sistema cambian cuando el negocio que procura el sistema responde a las presiones ex- 
ternas. Las prioridades de gestion cambian. Cuando se dispone de nuevas tecnologias, cam- 
bian los disefiosy la implementacion. Esto significaque el proceso del software no es unpro- 
ceso unico; mas bien, las actividades del proceso se repiten regularmente conforme el sistema 
se rehace en respuesta a peticiones de cambios. 

El desarrollo iterativo es tan fundamental para el software que se le dedica un capitulo com- 
plete del libro mas adelante (Capitulo 17). En esta seccion, se introduce el tema describien- 
do dos modelos de procesos que han sido disefiados explicitamente para apoyar la iteracion 
de procesos: 

1 . Entrega incremental. La especificacion, el disefio y la implementacion del software se 
dividen en una serie de incrementos, los cuales se desarrollan por turnos; 
. 2. Desarrollo en espiral. El desarrollo del sistema gira en espiral hacia fuera, empezan- 
do con un esbozo inicial y terminando con el desarrollo final del mismo. 

La esencia de los procesos iterativos es que la especificacion se desarrollajunto con el soft- 
ware. Sin embargo, esto crea conflictos con el modelo de obtencion de muchas organizacio- 
nes donde la especificacion completa del sistema es parte del contrato de desarrollo del mis- 
mo. En el enfoque incremental, no existe una especificacion completa del sistema hasta que 
el incremento final se especifica. Esto requiere un nuevo tipo de contrato, que a los clientes 
grandes como las agencias del gobierno les puede ser dificil de incorporar. 

4.2.1 Entrega Incremental 

El modelo de desarrollo en cascada requiere que los clientes de un sistema cumplan un con- 
junto de requerimientos antes de que se inicie el disefio y que el disefiador cumpla estrategias 
particulares de disefio antes de la implementacion. Los cambios de requerimientos implican 
rehacer el trabajo de captura de estos, de disefio e implementacion. Sin embargo, la separa- 
cion en el disefio y la implementacion deben dar lugar a sistemas bien documentados sus- 
ceptibles de cambio. En contraste, un enfoque de desarrollo evolutivo permite que los reque- 
rimientos y las decisiones de disefio se retrasen, pero tambien origina un software que puede 
estar debilmente estructurado y dificil de comprender y mantener. 

La entrega incremental (Figura 4.4) es un enfoque intermedio que combina las ventajas 
de estos modelos. En un proceso de desarrollo incremental, los clientes identifican, a gran- 
des rasgos, los servicios que proporcionarael sistema. Identifican que servicios son mas im- 
portantes y cuales menos. Entonces, se definen varios incrementos en donde cada uno pro- 
porciona un subconjunto de la funcionalidad del sistema. La asignacion de servicios a los 
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incrementos depende de laprioridad del servicio con los servicios de prioridad mas alta en- 
tregados primero. 

Una vez que los incrementos del sistema se han identificado, los requerimientos para los 
servicios que se van a entregar en el primer incremento se definen en detalle, y este se des- 
arrolla. Durante el desarrollo, se puede llevar a cabo un analisis adicional de requerimientos 
para los requerimientos posteriores, pero no se aceptan cambios en los requerimientos para el 
incremento actual. 

Una vez que un incremento se completa y entrega, los clientes pueden ponerlo en servicio. 
Esto significa que tienen una entrega temprana de parte de la funcionalidad del sistema. Pue- 
den experimentar con el sistema, lo cual les ayuda a clarificar sus requerimientos para los in- 
crementos posteriores y para las ultimas versiones del incremento actual. Tan pronto como se 
completan los nuevos incrementos, se integran en los existentes de tal forma que la funcio- 
nalidad del sistema mejora con cada incremento entregado. Los servicios comunes se pueden 
implementar al inicio del proceso o de forma incremental tan pronto como sean requeridos 
por un incremento. 

Este proceso de desarrollo incremental tiene varias ventajas: 

1. Los clientes no tienen que esperar hasta que el sistema completo se entregue para sa- 
car provecho de el. El primer incremento satisface los requerimientos mas criticos de 
tal forma que pueden utilizar el software inmediatamente. 

2. Los clientes pueden utilizar los incrementos iniciales como prototipos y obtener ex- 
periencia sobre los requerimientos de los incrementos posteriores del sistema. 

3. Existe un bajo riesgo de un fallo total del proyecto. Aunque se pueden encontrar pro- 
blemas en algunos incrementos, lo normal es que el sistema se entregue de forma sa- 
tisfactoria al cliente. 

4. Puesto que los servicios de mas alta prioridad se entregan primero, y los incrementos 
posteriores se integran en ellos, es inevitable que los servicios mas importantes del sis- 
tema sean a los que se les hagan mas pruebas. Esto significa que es menos probable 
que los clientes encuentren fallos de funcionamiento del software en las partes mas im- 
portantes del sistema. 

Sin embargo, existen algunos problemas en el desarrollo incremental. Los incrementos de- 
ben ser relativamente pequenos (no mas de 20.000 lineas de codigo) y cada uno debe entre- 
gar alguna funcionalidad del sistema. Puede ser dificil adaptar los requerimientos del cliente 
a incrementos de tamano apropiado. Mas aun, muchos de los sistemas requieren un conjunto 
de recursos que se utilizan en diferentes partes del sistema. Puesto que los requerimientos no 
se definen en detalle hasta que un incremento se implementa, puede ser dificil identificar los 
recursos comunes que requieren todos los incrementos. 
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Se ha desarrollado una variante de este enfoque incremental denominadaprogramacidn ex- 
trema (Beck, 2000). Esta se basa en el desarrollo y la entrega de incrementos de funcionali- 
dad muy pequeiios, en la participacion del cliente en el proceso, en la mejora constante del 
codigo y en la programacion por parejas. En el Capitulo 1 7 se estudia la programacion por 
parejas y otros llamados metodos agiles. 

4.2.2 Desarrollo en esplral 

El modelo en espiral del proceso del software (Figura 4.5) fue originalmente propuesto por 
Boehm (Boehm, 1988). Mas que representar el proceso del software como una secuencia de 
actividades con retrospectiva de una actividad a otra, se representa como una espiral. Cadaci- 
clo en la espiral representa una fase del proceso del software. Asi. el ciclo mas interno podria 
referirse a laviabilidad del sistema, el siguiente ciclo a ladefinicion de requerimientos, el si- 
guiente ciclo al diseno del sistema, y asi sucesivamente. 
Cada ciclo de la espiral se divide en cuatro sectores: 

1. Definition de objetivos. Para esta fase del proyecto se definen los objetivos especifi- 
cos. Se identifican las restricciones del proceso y el producto, y se traza un plan deta- 
llado de gestion. Se identifican los riesgos del proyecto. Etependiendo de estos ries- 
gos, se planean estrategias alternativas. 

2. Evaluation y reduction de riesgos. Se lleva a cabo un analisis detallado para cada uno 
de los riesgos del proyecto identificados. Se definen los pasos para reducir dichos ries- 
go. Por ejemplo, si existe el riesgo de tener requerimientos inapropiados, se puede 
desarrollar un prototipo del sistema. 
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Figura 4.5 Modelo en espiral de Boehm para el proceso del software (©IEEE, 1988). 
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3. Desarrollo y validation. Despues de la evaluacion de riesgos, se elige un modelo para 
el desarrollo del sistema. Por ejemplo, si los riesgos en la interfaz de usuario son do- 
minantes, un modelo de desarrollo apropiado podria ser la construccion de prototipos 
evolutivos. Si los riesgos de seguridad son laprincipalconsideracion,un desarrollo ba- 
sado en transformaciones formales podria ser el mas apropiado, y asi sucesivamente. 
El modelo en cascada puede ser el mas apropiado para el desarrollo si el mayor ries- 
go identificado es la integracion de los subsistemas. 

4. Planiflcacion. El proyecto se revisa y se toma la decision de si se debe continuar con 
un ciclo posterior de la espiral. Si se decide continuar, se desarrollan los planes para 
la siguiente fase del proyecto. 

La diferencia principal entre el modelo en espiral y los otros modelos del proceso del soft- 
ware es laconsideracionexplicitadel riesgo en el modelo en espiral. Informalmente, el ries- 
go significa sencillamente algo que puede ir mal. Por ejemplo, si la intencion es utilizarun 
nuevo lenguaje de programacion, un riesgo es que los compiladores disponibles sean poco 
fiables o que no produzcan codigo objeto suficientemente eficiente. Los riesgos originan pro- 
blemas en el proyecto, como los de confeccion de agendas y excesos en los costos; por lo 
tanto, la disminucion de riesgos es una actividad muy importante en la gestion del proyecto. 
La gestion de los riesgos, una parte fundamental en la gestion de proyectos, se trata en el Ca- 
pitulo 5. 

Un ciclo de la espiral empieza con la elaboracion de objetivos, como el rendimiento y la 
funcionalidad. Entonces se enumeran formas alternativas de alcanzar estos objetivos y las 
restricciones impuestas en cada una de ellas. Cada alternativa se evalua contra cada objeti- 
vo y se identifican las fuentes de riesgo del proyecto. El siguiente paso es resolver estos ries- 
gos mediante actividades de recopilacion de informacion como la de detallar mas el anali- 
sis, la construccion de prototipos y la simulacion. Una vez que se han evaluado los riesgos, 
se lleva a cabo cierto desarrol lo. seguido de una actividad de planificacion para la siguien- 
te fase del proceso. 



43 Actividades del proceso 

Las cuatro actividades basicas del proceso de especificacion, desarrollo, validacion y evolu- 
cion se organizan de forma distinta en diferentes procesos del desarrollo. En el enfoque en cas- 
cada, estan organizadas en secuencia, mientras que en el desarrollo evolutivo se entrelazan. 
Como se llevan a cabo estas actividades depende del tipo de software, de las personas y de la 
estructura organizacion al implicadas. No hay una forma correcta o incorrecta de organizares- 
tas actividades, y el objetivo de esta seccion es simplemente proporcionar una introduccion 
de como se pueden organizar. 

4.3.1 Especificacion del software 

La especificacion del software o ingenieria de requerimientos es el proceso de comprension 
y definicion de que servicios se requieren del sistema y de identificacion de las restricciones 
de funcionamiento y desarrollo del mismo. La ingenieria de requerimientos es una etapa par- 
ticularmente critica en el proceso del software ya que los errores en esta etapa originan in- 
evitablemente problemas posteriores en el diseflo e implementacion del sistema. 
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En la Figura 4.6 se muestra el proceso de ingenieria de requerimientos. Este conduce a 
la produccion de un documento de requerimientos, que es la especificacion del sistema. 
Normalmente en este documento los requerimientos se presentan en dos niveles de detalle. 
Los usuarios finales y los clientes necesitan una declaracion de alto nivel de los requeri- 
mientos, mientras que los desarrolladores del sistema necesitan una especificacion mas de- 
tallada de este. 

Existen cuatro fases principales en el proceso de ingenieria de requerimientos: 

1 . Estudio de viabilidad. Se estima si las necesidades del usuario se pueden satisfacer con 
las tecnologias actuales de software y hardware. El estudio analiza si el sistema pro- 
puesto sera rentable desde un punto de vista de negocios y si se puede desarrollar den- 
tro de las restricciones de presupuesto existentes. Este estudio debe ser relativamente 
economico y rapido de elaborar. El resultado debe informar si se va a continuar con 
un analisis mas detallado. 

2. Obtenciony analisis de requerimientos. Es el proceso de obtener los requerimientos 
del sistema por medio de la observacion de los sistemas existentes, discusiones con los 
usuarios potenciales y proveedores, el analisis de tareas, etcetera. Esto puede implicar 
el desarrollo de uno o mas modelos y prototipos del sistema que ayudan al analista a 
comprender el sistema a especificar. 

3. Especificacion de requerimientos. Es la actividad de traducir la informacion recopila- 
da durante la actividad de analisis en un documento que define un conjunto de reque- 
rimientos. En este documento se pueden incluir dos tipos de requerimientos: los re- 
querimientos del usuario, que son declaraciones abstractas de los requerimientos del 
cliente y del usuario final del sistema, y los requerimientos del sistema, que son una 
descripcion mas detallada de la funcionalidad a proporcionar. 

4. Validation de requerimientos. Esta actividad comprueba laveracidad, consistenciay 
completitud de los requerimientos. Durante este proceso, inevitablemente se descu- 
bren errores en el documento de requerimientos. Se debe modificar entonces para co- 
rregir estos problemas. 

Por supuesto, las actividades en el proceso de requerimientos no se llevan a cabo de forma 
estrictamente secuencial. El analisis de requerimientos continua durante la definicion y espe- 
cificacion, y a lo largo del proceso surgen nuevos requerimientos. Por lo tanto, las activida- 
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Figura 4.6 El proceso de la ingenieria de requerimientos. 



des de analisis, definicion y especificacion se entrelazan. En los metodos agiles como la pro- 
gramacion extrema, los requerimientos de desarrollan de forma incremental conforme a las 
prioridades del usuario, y la obtencion de requerimientos viene de los usuarios que forman 
parte del equipo de desarrollo. 

4.3.2 Diseno e Implementaclon del software 

La etapa de implementacion del desarrollo de software es el proceso de convertir una especi- 
ficacion del sistema en un sistema ejecutable. Siempre implica los procesos de diseno y pro- 
gramacion de software, pero, si se utiliza un enfoque evolutivo de desarrollo, tambien puede 
implicarun refinamiento de la especificacion del software. 

Un diseno de software es una descripcion de la estructura del software que se va a imple- 
mentar, los datos que son parte del sistema, las interfaces entre los componentes del sistema 
y, algunas veces, los algoritmos utilizados. Los disenadores no llegan inmediatamente a un di- 
seno detallado, sino que lo desarrollan de manera iterativa a traves de diversas versiones. El 
proceso de diseno conlleva agregar formalidad y detalle durante el desarrollo del diseno, y re- 
gresara los disenos anteriores para corregirlos. 

El proceso de diseno puede implicar el desarrollo de varios modelos del sistema con diferentes 
niveles de abstraccion. Mientras se descomponeun diseno, se descubren erroresy omisionesde 
las etapas previas. Esta retroalimentacion permite mejorar los modelos de diseno previos. La F i - 
gura4.7 es un modelo de este proceso que muestra las descripciones de diseno que pueden pro- 
ducirse en varias etapas del diseno. Este diagrama sugiere que las etapas son secuenciales. En 
realidad, las actividades del proceso de diseno se entrelazan. La retroalimentacion entre etapas 
y la consecuente repeticion del trabajo es inevitable en todos los procesos de diseno . 

Una especificacion para la siguiente etapa es la salida de cada actividad de diseno . Esta es- 
pecificacion puede ser abstracta y formal, realizada para clarificar los requerimientos, o pue- 
de seruna especificacion para determinar que parte del sistema se va a construir. Durante todo 
el proceso de diseno, se detalla cada vez mas esta especificacion. El resultado final del pro- 
ceso son especificaciones precisas de los algoritmos y estructuras de datos a implementarse. 

Las actividades especificas del proceso de diseno son: 

1. Diseno arquitectdnico. Los subsistemas que forman el sistema y sus relaciones se 
identifican y documentan. En los Capitulos 11, 12y 13 se trata este importante tema. 




Productos del diseno 
Figura 4.7 Un modelo general del proceso de diseno. 
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2. Especificacion abstracta. Para cada subsistema se produce una especificacion abs- 
tracta de sus servicios y las restricciones bajo las cuales debe funcionar. 

3. Diseho de la interfaz. Para cada subsistema se disefia y documenta su interfaz con 
otros subsistemas. Esta especificacion de la interfaz debe ser inequivoca ya que per- 
mite que el subsistema se utilice sin conocimiento de su funcionamiento. En esta eta- 
pa pueden utilizarse los metodos de especificacion formal que se describen en el Ca- 
pitulo 10. 

4. Diseho de componentes. Se asignan servicios a los componentes y se disefian sus in- 
terfaces. 

5. Diseho de la estructura de datos. Se disefia en detalle y especifica la estructura de da- 
tes utilizada en la implementacion del sistema. 

6. Diseho de algoritmos. Se disefian en detalle y especifican los algoritmos utilizados 
para proporcionar los servicios. 

Este es un modelo general del proceso de diseno, y los procesos reales y practicos pueden 
adaptarlo de diversas maneras. He aqui algunas adaptaciones posibles: 

1. Las dos ultimas etapas — diseno de la estructura de datos y de algoritmos — se pue- 
den retrasar hasta la etapa de implementacion. 

2. Si seutilizaunenfoque exploratorio de diseno, las interfaces del sistema se pueden di- 
senardespues de que se especifiquen las estracturas de datos. 

3. Se puede omitir la etapa de especificacion abstracta, aunque normalmente es una par- 
te fundamental del diseno de sistemas criticos. 

Cada vez mas, cuando se utilizan metodos agiles de desarrollo (vease el Capitulo 17), las 
salidas del proceso de diseno no seran documentos de especificacion separados, sino que es- 
taran representadas en el codigo del programa. Una vez disenada la arquitectura de un siste- 
ma, las etapas posteriores del diseno son incrementales. Cada incremento se representa como 
codigo del programa en vez de como un modelo de diseno. 

Un enfoque opuesto es dado por los metodos estructurados que se basan en la produc- 
cion de modelos graficos del sistema (vease el Capitulo 8) y, en muchos casos, codigo au- 
tomaticamente generado desde estos modelos. Los metodos estructurados se inventaron en 
los anos 70 en apoyo del diseno orientado a funciones (Constantine y Yourdon, 1979; Gane 
y Sarson, 1979). Se propusieron varios modelos competentes de apoyo al diseno orientado 
a objetos (Robinson, 1992; Booch, 1994) y estos se unificaron en los anos 90 para crear el 
LenguajeUnificado de Modelado (UML) y el proceso unificado de diseno asociado (Rum- 
baugh *?*a/., 1991; Booch etal., 1999; Rumbaugh etal., 1999a; Rumbaugh etal.. 1999b). 
En el momentode escribireste libro, una revision importante del UM L (UML 2.0) esta en 
marcha. 

Un metodo estructurado incluye un modelo del proceso de diseno, notaciones para repre- 
sentar el diseno, formates de informes, reglas y pautas de diseno. Los metodos estructurados 
pueden ayudar a alguno o a la totalidad de los siguientes modelos de un sistema: 

1 . Un modelo que objetos que muestra las clases de objetos utilizadas en el sistema y sus 
dependencias. 

2. Un modelo de secuencias que muestra como interactuan los objetos en el sistema 
cuando este se ejecuta. 

3. Un modelo del estado de transicion que muestra los estados del sistema y los dispara- 
dores de las transiciones desde un estado a otro. 
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4. Un modelo estructural en el cual se documentan los componentes del sistema y sus 
agregaciones. 

5. Un modelo de flujo de datos en el que el sistema se modela utilizando la transforma- 
cion de datos que tiene lugar cuando se procesan. Este no se utiliza normalmente en 
los metodos orientados a objetos, pero todavia se utiliza frecuentemente en el diseno 
de sistemas de tiempo real y de negocio. 

En la practica, los «metodos» estructurados son realmente notaciones estandarque com- 
prenden practicas aceptables. Si se siguen estos metodos y se aplican las pautas, puede obte- 
nerse un diseno razonable. La creatividad del disenador aun se requiere para decidir la des- 
composiciondel sistema y asegurar que el diseno capte de forma adecuada la especificacion 
del mismo. Los estudios empiricos de los disefiadores (Banslery Bcidker, 1993) muestran que 
estos raramente siguen los metodos convencionales. Seleccionan y eligen de las pautas segun 
circunstancias locales. 

El desarrollo de un programa para implementar el sistema se sigue de forma natural del 
proceso de diseno. Aunque algunos programas, como los de los sistemas criticos de seguri- 
dad, se disefian en detalle antes de que se inicie cualquier implementacion. es mas comun que 
las primeras etapas de diseno y desarrollo de programas esten entrelazadas. Las herramientas 
C A S E se pueden utilizar para generar un programa esqueleto a partir de un diseno. Esto in- 
cluye codigo para definir e implementar las interfaces, y en muchos casos el desarrollador solo 
necesita agregar detalles del funcionamiento de cada componente del programa. 

La programacion es una actividad personal y no existe un proceso general que se siga co- 
munmente. Algunos programadores empiezan con los componentes que comprenden, los 
desarrollan y despues continuan con los que comprenden menos. Otros toman el enfoque 
opuesto, dejando los componentes que son mas familiares hasta el final debido a que saben 
como desarrollarlos. Algunos desarrolladores prefieren definir los datos al inicio del proceso 
y los utilizan para conducir el desarrollo del programa; otros dejan los datos sin especificar 
tanto como sea posible. 

Normalmente, los programadores llevan a cabo algunas praebas del codigo que han des- 
arrollado. A menudo esto muestra defectos en el programa que se deben eliminar del mismo. 
Esto se denomina depuration. Las pruebas y la depuracion de defectos son procesos diferen- 
tes. Las pruebas establecen la existencia de defectos. La depuracion comprende la localiza- 
cion y correccion de estos defectos. 

La Figura 4.8 ilustra las etapas de la depuracion. Los defectos en el codigo se localizan y 
el programa se modifica para cumplir los requerimientos. Las praebas se deben entonces re- 
petirpara asegurar que los cambios se han efectuado correctamente. Asi, el proceso de depu- 
racion es parte tanto del desarrollo como de las praebas del software. 

Al depurar, se generan hipotesis acerca del comportamiento que se observa en el pro- 
grama; despues, se praeban estas hipotesis con la esperanza de encontrar el defecto que ori- 
gina la anomalia en la salida. Probar las hipotesis puede implicar realizaruna traza manual 
del codigo del programa. Pueden escribirse nuevos casos de praebas para localizar el pro- 
blema. Para ayudaral proceso de depuracion, se pueden utilizar herramientas de depuracion 
interactiva que muestran los valores intermedios de las variables del programa y una traza 
de las sentencias ejecutadas. 
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4.3.3 Valldaclon del software 

La validacion del software o, de forma mas general, la verificacion y validacion (V & V) se 
utiliza para mostrar que el sistema se ajusta a su especificacion y que cumple las expectativas 
del usuario que lo comprara. Implica procesos de comprobacion, como las inspecciones y re- 
visiones (vease el Capitulo 22), en cadaetapadelproceso del software desde ladefinicionde 
requerimientos hasta el desarrollo del programa. Sin embargo, la mayoria de los costos de va- 
lidacion aparecen despues de la implementacion, cuando se prueba el funcionamiento del sis- 
tema (Capitulo 23). 

A excepcion de los programas pequenos, los sistemas no se deben probarcomo una sim- 
ple unidad monolitica. La Figura 4.9 muestra un proceso de pruebas de tres etapas en el cual 
se prueban los componentes del sistema, la integracion del sistema y, finalmente, el sistema 
con los datos del cliente. En el mejor de los casos, los defectos se descubren en las etapas ini- 
ciales del proceso y los problemas con la interfaz, cuando el sistema se integra. Sin embargo, 
cuando se descubren defectos el programa debe depurarse y esto puede requerir la repeticion 
de otras etapas del proceso de pruebas. Los errores en los componentes del programa pueden 
descubrirse durante las pruebas del sistema. Por lo tanto, el proceso es iterativo y se retroali- 
menta tanto de las ultimas etapas como de la primera parte del proceso. 

Las etapas del proceso de pruebas son: 

1 . Prueba de componentes (o unidades). Se prueban los componentes individuales para 
asegurarse de que funcionan correctamente. Cada uno se prueba de forma indepen- 
diente, sin los otros componentes del sistema. Los componentes pueden ser entidades 
simples como funciones o clases de objetos, o pueden ser agrupaciones coherentes de 
estas entidades. 

2. Prueba de! sistema. Los componentes se integranpara formarel sistema. Esle proce- 
so comprende encontrar errores que son el resultado de interacciones no previstas en- 
tre los componentes y su interfaz. Tambien comprende validar que el sistema cumpla 
sus requerimientos funcionales y no funcionales y probar las propiedades emergentes 
del sistema. Para sistemas grandes, esto puede ser un proceso gradual en el cual los 
componentes se integran para formar subsistemas que son probados individualmente 
antes de que ellos mismos se integren para formar el sistema final. 

3. Prueba de aceptacion. Es la etapa final en el proceso de pruebas antes de que se acep- 
te que el sistema se ponga en funcionamiento. Este se prueba con los datos propor- 
cionados por el cliente mas que con datos de prueba simulados. Debido a la diferen- 
cia existente entre los datos reales y los de prueba, la prueba de aceptacion puede 
revelar errores y omisiones en la definicion de requerimientos del sistema. Tambien 
puede revelar problemas en los requerimientos donde los recursos del sistema no cum- 
plen las necesidades del usuario o donde el desempeflo del sistema es inaceptable. 

Normalmente, el desarrollo de componentes y las pruebas se entrelazan. Los programa- 
dores definen sus propios datos de prueba y de forma incremental prueban el codigo que se 
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va desarrollando. Este es un enfoque economicamente razonable puesto que el programador 
es el que mejor conoce los componentes y es, por lo tanto, la mejor persona para generar los 
casos de prueba. 

Si se utilizaun enfoque incremental de desarrollo, cada incremento debe serprobado cuan- 
do se desarrolla, con estas pruebas basadas en los requerimientos de ese incremento. En la pro- 
gramacion extrema, las pruebas se desarrollan junto con los requerimientos antes de que em- 
piece el desarrollo. Esto ayuda a los probadores y desarrolladores a entender los requerimientos 
y asegurar que no hay retardos pues se crean los casos de prueba. 

Las ultimas etapas de prueba consisten en integrar el trabajo de los programadores y de- 
ben planificarse por adelantado. Un equipo independiente de probadores debe trabajar a par- 
tir de planes de prueba que se desarrollan desde de la especificacion y diseno del sistema. La 
Figura 4.10 ilustra como los planes de prueba son el vinculo entre las actividades de prueba 
yde desarrollo. 

La prueba de aceptacion algunas veces se denomina prueba alfa. Los sistemas personali- 
zados se desarrollan para un unico cliente. El proceso de prueba alfa continua hasta que el 
desarrollador del sistema y el cliente acuerdan que el sistema que se va a entregar es una im- 
plementacion aceptable de los requerimientos del sistema. 

Cuando un sistema se va a comercializar como un producto de software, a menudo se uti- 
liza un proceso de prueba denominado prueba beta. Esta comprende la entrega de un siste- 
ma a un numero potencial de clientes que acuerdan utilizarlo, los cuales informan de los 
problemas a los desarrolladores del sistema. Esto expone el producto a un uso real y detecta 
los errores no identificados por los constructores del sistema. Despues de esta retroalimen- 
lacion, el sistema se modifica y se entrega ya sea para una prueba beta adicional o para la 
venta. 

4.3.4 Evolucldn del software 

La flexibilidad de los sistemas software es una de las principales razones por la que mas y 
mas software se incorpora a los sistemas grandes y complejos. Una vez que se decide adquirir 
hardware, es muy costoso hacer cambios en su diseno. Sin embargo, se pueden hacer cam- 
bios al software en cualquier momento durante o despues del desarrollo del sistema. Aun 
cambios importantes son todavia mucho mas economicos que los correspondientes de los sis- 
temas hardware. 




Figura 4.10 Las fases de prueba en el proceso del software. 
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Figura 4.11 
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Historicamente, siempre ha existido una separacion entre el proceso de desarrollo y el pro- 
ceso de evolucion del software (mantenimiento del software). La gente considera el desarro- 
llo de software como una actividad creativa en la cual un sistema software se desarrolla des- 
de un concepto inicial hasta que se pone en funcionamiento. Sin embargo, a veces consideran 
el mantenimiento del software como algo aburrido y sin interes. Aunque los costos de «man- 
tenimiento» son a menudo varias veces los costos iniciales de desarrollo, el proceso de man- 
tenimiento se considera a veces menos problematico que el desarrollo del software original. 

Esta distincion entre el desarrollo y el mantenimiento es cada vez mas irrelevante. Hoy en 
dia, pocos sistemas software son completamente nuevos, lo que implica que tiene mas senti- 
do ver el desarrollo y el mantenimiento como actividades continuas. Mas que dos procesos 
separados, es mas realista considerar a la ingenieria del software como un proceso evolutivo 
(Figura 4. 1 1 ) en el cual el software se cambia continuamente durante su periodo de vida como 
respuesta a los requerimientos cambiantes y necesidades del usuario. 

4.4 El Proceso Unificado de Rational 

El Proceso Unificado de Rational (RUP) es un ejemplo de un modelo de proceso moder- 
no que proviene del trabajo en el U M L y el asociado Proceso Unificado de Desarrollo de Soft- 
ware (Rumbaugh etai., 1999b) A Se ha incluido aqui una descripcion ya que es un buen ejem- 
plo de un modelo de proceso hibrido. Reune elementos de todos los modelos de procesos 
genericos (Secci6n4.1), iteraciones de apoyo (Secci6n4.2) e ilustra buenas practicas en laes- 
pecificacion y el disefio (Seccion 4.3). 

El RUP reconoce que los modelos de procesos genericos presentan un sola enfoque del 
proceso. En contraste, el RUP se describe normalmente desde tres perspectivas: 

1 . Una perspectiva dinamica que muestra las fases del modelo sobre el tiempo. 

2. Una perspectiva estatica que muestra las actividades del proceso que se representan. 

3. Una perspectiva practica que sugiere buenas practicas a utilizar durante el proceso. 

La mayorparte de las descripciones del RUP intentan combinar las perspectivas estatica y 
dinamica es un unico diagrama (Krutchen. 2000). Esto hace el proceso mas dificil de enten- 
der, por lo que aqui se utilizan descripciones separadas de cada una de estas perspectivas. 

El RUP es un modelo en fases que identifica cuatro fases diferentes en el proceso del soft- 
ware. Sin embargo, adiferencia del modelo en cascada donde las fases se equiparan con las 
actividades del proceso, las fases en el RUP estan mucho mas relacionadas con asuntos de ne- 
gocio mas que tecnicos. La Figura 4.12 muestra las fases en el RUP. Estas son: 

1. Inicio. El objetivo de la fase de inicio es el de establecer un caso de negocio para el 
sistema. Se deben identificar todas las entidades externas (personas y sistemas) que 
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inleractuaran con el sistema y definir estas interacciones. Esta informacion se utiliza 
entonces para evaluar la aportacion que el sistema hace al negocio. Si esta aportacion 
es de poca importancia, se puede cancelar el proyecto despues de esta fase. 
1/' 2. Elaboration. Losobjetivosdelafasedeelaboracionsondesarrollarunacomprension 
del dominio del problema, establecerun marco de trabajo arquitectonico para el sis- 
tema, desarrollar el plan del proyecto e identificar los riesgos clave del proyecto. Al 
terminar esta fase, se debe tener un modelo de los requerimientos del sistema (se es- 
pecifican los casos de usoUML), una descripcion arquitectonica y un plan de des- 
arrollo del software. 

/ 3. Construction. La fase de construccion fundamentalmente comprende el diseno del sis- 
tema, la programacion y las pruebas. Durante esta fase se desarrollan e integran las 
partes del sistema. Al terminar esta fase, debe tener un sistema software operativo y 
la documentacion correspondiente lista para entregarla a los usuarios. 
4. Transition. La fase final del RUP se ocupa de mover el sistema desde la comunidad 
de desarrollo a la comunidad del usuario y hacerlo trabajar en un entorno real. Esto 
se deja de lado en la mayor parte de los modelos de procesos del software pero es, 
en realidad, una actividad de alto costo y a veces problematica. Al terminar esta fase, 
se debe tener un sistema software documentado que funciona correctamente en su 
entorno operativo. 

La iteraciondentro del RUP es apoyadade dos formas, como se muestraen laFigura4.12. 
Cada fase se puede representar de un modo iterativo con los resultados desarrollados incre- 
mentalmente. Ademas, el conjunto entero de fases puede tambien representarse de forma in- 
cremental, como se muestra en la citada figura por la flecha en forma de bucle desde la Tran- 
sicion hasta el Inicio. 

La vista estatica del RUP se centra en las actividades que tienen lugar durante el proceso 
de desarrollo. Estas se denominan/Zi#/7wf de trabajo en la descripcion del RUP. Existen seis 
principales flujos de trabajo del proceso identificados en el proceso y tres principales flujos 
de trabajo de soporte. El RUP se ha disefiado conjuntamente con el U M L — un lenguaje de 
modelado orientado a objetos — , por lo que la descripcion del flujo de trabajo se orienta al- 
rededor de los modelos U M L asociados. En la Figura 4.13 se describen los principales flujos 
de trabajo de ingenieria y de soporte. 

La ventaja de presentar perspectivas dinamicas y estaticas es que las fases del proceso de 
desarrollo no estan asociadas con flujos de trabajo especificos. Al menos en principio, todos 
los flujos de trabajo del RUP pueden estar activos en todas las etapas del proceso. Por su- 
puesto, la mayor parte del esfuerzo se realizara en flujos de trabajo tales como el modelado 
del negocio y los requerimientos en las primeras fases del proceso y en las pruebas y des- 
pliegue en las fases posteriores. 
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Figure 4.13 Flujos de trabajo estdticos en el Proceso Unificado de Rational. 



Laperspectivapracticaen el RUP describe buenas practicas de la ingenieria del software 
que son aconsejables en el desarrollo de sistemas. Se recomiendan seis buenas practicas fun- 
damentales: 

1. Desarrolle el software de forma iterativa. Planifique incrementos del sistema basado 
en las prioridades del usuario y desarrollo y entregue las caracteristicas del sistema de 
mas altaprioridad al inicio del proceso de desarrollo. 

2. Gestione los requerimientos. Documente explicitamente los requerimientos del clien- 
te y mantengase al tanto de los cambios de estos requerimientos. Analice el impacto 
de los cambios en el sistema antes de aceptarlos. 

3 . Utilice arquitecturas basadas en componentes. Estructure la arquitectura del sistema 
en componentes como se indico anteriormente en este capitulo. 

4. Modele el software visualmente. Utilice modelos graficos U M L para presentar vistas 
estaticas y dinamicas del software. 

5. Verifique la calldad del software. Asegure que el software cumple los estandares de 
calidad organizacionales. 

6. Controle los cambios del software. Gestione los cambios del software usando un sis- 
tema de gestion de cambios y procedimientos y herramientas de gestion de configu- 
raciones (vease el Capitulo 29). 

El RUP no es un proceso apropiado para todos los tipos de desarrollo sino que representa 
una nueva generacion de procesos genericos. Las innovaciones mas importantes son la se- 
paracion de fases y los flujos de trabajo, y el reconocimiento de que la utilizacion del soft- 
ware en un entorno del usuario es parte del proceso. Las fases son dinamicas y tienen ob- 
jetivos. Los flujos de trabajo son estaticos y son actividades tecnicas que no estan asociadas 
con fases unicas sino que pueden utilizarse durante el desarrollo para alcanzar los objeti- 
vos de cada fase. 
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4.5 Ingenieria del Software Asistida por computadora 

Ingenieria del Software Asistida por Computadora (CASE) es el nombre que se le da al soft- 
ware que se utiliza para ayudar a las actividades del proceso del software como la ingenieria 
de requerimientos, el diseno, el desarrollo de programas y las pruebas. Por lo tanto, las he- 
rramientas CASE incluyen editores de diseno, diccionarios de datos, compiladores, depura- 
dores, herramientas de construccion de sistemas, etcetera. 

La tecnologia C A S E proporciona ayuda al proceso del software automatizando algunas de 
sus actividades, asi como proporcionando informacion acerca del software en desarrollo. A 1 - 
gunos ejemplos de las actividades que se pueden automatizar utilizando CASE son: 

1. El desarrollo de modelos graficos del sistema como parte de la especificacion de re- 
querimientos o del diseno de software. 

2. La comprension del diseno utilizando un diccionario de datos que tiene informacion 
sobre las entidades y relaciones del diseno. 

3. Lageneracion de interfaces de usuario a partir de la descripcion grafica de la interfaz 
que es elaborada de forma interactiva por el usuario. 

4. La depuracion de programas por medio de la provision de la informacion proporcio- 
nada por los programas en ejecucion. 

5. La conversion automatica de programas de una version anterior de una lenguaje de 
programacion, como COBOL, a una version mas reciente. 

La tecnologia CASE esta disponible para la mayoria de las actividades rutinarias en el pro- 
ceso del software. Esto permite algunas mejoras en la calidad y productividad del software, aun- 
que estas sean menores que las predichas por los primeros partidarios de CASE. Estos sugirie- 
ron que se tendria una mejora mayor si se utilizaran entornos CASE integrados. En realidad, las 
mejoras reales son del 40% (Huff, 1992). Aunque esto es significante, las predicciones que se 
hicieron cuando se introdujeron las herramientas CASE en los aftos 80 y 90 fueron que el uso 
de la tecnologia C A SE generaria enormes ahorros en los costos del proceso del software. 

Las mejoras por la utilizacion de CASE estan limitadas por dos factores: 

1. Esencialmente, la ingenieria del software es una actividad de diseno que se basaen la 
creatividad. Los sistemas CASE automatizan las actividades rutinarias, pero los in- 
tentos de utilizar la inteligencia artificial para proporcionar ayuda al diseno no han te- 
nido exito. 

2. En la mayoria de las organizaciones, la ingenieria del software es una actividad de 
equipo, y los ingenieros invierten mucho tiempo interactuando con los otros miembros 
del equipo, La tecnologia C ASE no proporciona mucha ayuda para esto. 

Actualmente, la tecnologia C A S E esta madura y hay herramientas disponibles y bancos de 
trabajo de un amplio rango de proveedores. Sin embargo, mas que centrarse en alguna herra- 
mienta especifica, aqui se presenta una vision general, con algunos comentarios de apoyo es- 
pecifico en otros capitulos. En la pagina web se incluyen enlaces a otro material de CASE y 
a proveedores de herramientas CASE. 

4.5.1 Claslflcacldn de CASE 

Las clasificaciones de CASE nos ayudan a comprender los tipos de herramientas CASE y su 
papel en la ayuda a las actividades de proceso del software. Existen varias formas diferentes 
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de clasificar las herramientas CASE, cada una de las cuales nos proporciona una perspectiva 
distinta de estas herramientas. En esta seccion, se describen dichas herramientas desde tres de 
estas perspectivas: 

1 . Una perspectiva funcional en la que las herramientas C A S E se clasifican de acuerdo 
con su funcion especifica. 

2 . Una perspectiva de proceso en la que las herramientas se clasifican de acuerdo con las 
actividades del proceso que ayudan. 

3. Una perspectiva de integration en la que las herramientas CASE se clasifican de 
acuerdo con la forma en que estan organizadas en unidades integradas que proporcio- 
nan ayuda a una o mas actividades del proceso. 

La Figura 4.14 es una clasificacion de las herramientas CASE acorde con su funcion. Esta 
tabla enumera diferentes tipos de herramientas C A S E y da ejemplos especificos de cada una. 
Esta no es una lista completa de herramientas C A S E . Las herramientas especializadas, como 
las de ayuda a la reutilizacion, no se incluyen. 

La Figura 4.15 presenta una clasificacion alternativa de las herramientas CASE. Muestra 
las fases del proceso que reciben ayuda por varios tipos de herramientas CASE. Las herra- 
mientas para laplanificacion y estimacion, edicion de texto, preparacion de documentos y ges- 
tion de la configuracion pueden utilizarse durante todo el proceso del software. 

Ora dimension de clasificacion posible es la amplia ayuda que ofrece la tecnologia CASE 
para el proceso del software. Fuggetta (Fuggetta, 1993) propone que los sistemas CASE se 
deben clasificar en tres categorias: 

1. Las herramientas ayudan a las tareas individuals del proceso como la verificacion de 
la consistencia de un disefio, la compilacion de un programa y la comparacion de los 
resultados de las pruebas. Las herramientas pueden ser de proposito general, inde- 
pendientes (por ejemplo, un procesador de texto) o agrupadas en bancos de trabajo. 

2. Los bancos de trabajo ayudan a las fases o actividades del proceso como la especifi- 
cacion, el disefio, etcetera. Normalmente consisten en un conjunto de herramientas con 
algun grado mayor o menorde integracion. 





Herramientas de planjficaci6n 


Herramientas PERT, herramientas de estimacion, hojas de cilculo. 


Herramientas de edicion 


Editor es de texto, editores de diagramas, pracesadores de texto. 


Herramientas de gestion del camhio 


Herramientas de rastreo de requerimientos, sistemas de control de eambios. 


Herramientas de gesrJ6n de la configuracion 


Sistema de gesb6n de las version es, herramientas de construccion de sistemas. 


Herramientas de con struct: i6n de prototipos 


Lenguajes de muy alto nivel, generadores de interfaz de usuario. 


Herramientas de apoyo a metodos 


Editores de disefio, diccionarios de datos, generadores de todigo. 


Herramientas de procesamiento de lenguajes 


Compiladores, int&pretes. 


Herramientas de analisis de programas 


Generadores de referendas cruzadas, analizadores estiticos, analizadores dinamicos. 


Heiramientas de piuebas 


Generadores de pmebas de datos, comparadores de archrvos. 


Herramientas de depuracion 


Sistemas de depuraci6n irrteractiva. 



Herramtentas de docurnerttacion Programas de disefio de paginas, editores de imigenes. 



Herramientas de reingenierla Sistemas de referencias cruzadas, sistemas reestructuraci6n de programas. 

Figura 4.14 Clasificacion funcional de las herramientas CASE. 
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Figura 4.15 
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Especificaci6n Diseno Implementation Verification y 

validation 



3. Los entornos ayudan a todos los procesos del software, o al menos a una parte sus- 
tancial de estos. Normalmente incluyen varios bancos de trabajo integrados. 

La Figura 4. 1 6 ilustra esta clasificacion y muestra algunos ejemplos de estas clases de ayu- 
da CASE. Por supuesto, esto es un ejemplo ilustrativo: muchos tipos de herramientas y ban- 
cos de trabajo se han quedado fuera de este diagrama. 

Las herramientas de proposito general se utilizan a discrecion del ingeniero de software 
quien toma decisiones acerca de cuando aplicarlas para ayudaral proceso. Sin embargo, los 
bancos de trabajo por lo general ayudan a algun metodo que incluye un modelo del proceso 
y un conjunto de reglas/pautas que se aplican al software en desarrollo. Los entornos se cla- 
sifican en integrados y centrados en el proceso. Los entornos integrados proporcionan ayuda 
a los datos, al control y a la integracion de la presentacion. Los entornos centrados en proce- 
sos son mas generales. Incluyen el conocimiento del proceso del software y un motor de pro- 
cesos que utiliza este modelo del proceso para aconsejar a los ingenieros sobre que herra- 
mientas o bancos de trabajo hay que aplicar y cuando deben utilizarse. 

En la practica, los Hmites entre estas diferentes clases son borrosos. Las herramientas se 
pueden vender como productos individuales, pero pueden proporcionar ayuda a diferentes ac- 
tividades. Por ejemplo, la mayoria de los procesadores de texto incluyen un editor de diagra- 
mas integrado. Los bancos de trabajo CASE para el diseno normalmente ayudan a la progra- 
macion y a las pruebas, de tal forma que se relacionan mas con el entorno que con los bancos 
de trabajo especializados. Por tanto, puede que no siempre resulte facil ubicar un producto uti- 
lizando una clasificacion. No obstante, la clasificacion proporciona un primer paso util para 
ayudara entender la amplitud del soporte que una herramienta proporciona al proceso. 
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Figura 4.16 Herramientas, bancos de trabajo y entornos. 



PUINTTOS CLAVE 

• Los procesos del software son las actividades relacionadas con laproduccidndeun sistema software. Los mo- 
delos del proceso del software son representaciones abstractas de estos procesos. 

• Todos I os procesos del software incluyen la especificacion, eld i sen o, ta Implementation, lavalidacionyla evo- 
lucion del software. 

• Los modelos genericos del proceso describen la organizacion de Los procesos del software. Ejemplos de es- 
tos modelos son el modelo en cascada, el desarrollo evolutivo y la ingenieria del software basada en compo- 
nentes. 

• Los modelos de iteracion de procesos presentan el proceso del software como un ciclo de actividades. La ven- 
taja de este enroque es que evita compromisos prematuras con una especificacion odiseno. Ejemplos deeste 
tipo de modelos son el desarrollo incremental y el modelo en espiral. 

• La Ingenieria de requerimientos esel proceso de desarrollaruna especificacion del software. Las especif ica- 
ciones pretenden comunicar las necesidades del sistema del cliente a Los desarroltadores del sistema. 

• Los procesos de diseho e implementation comprenden ta transformacidn de (a especificacion de los requeri- 
mientos en un sistema software ej ecu table. Los m etodossistemati cos dedi sen osepuedenuti lizar como par- 
te de esta transformacion. 
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• La validacion del software es el proceso de verificar que el sistema se ajusta a su especif icacion yque satis- 
face las necesidades reales de los usuarios del sistema. 

• La evolucion del software se interesa en modificar los sistemas software existentes para cumplir los nuevos 
requerimientos. Esto se esta conviniendo en el enfoque normal para el desarrollo de sistemas de pequeno y 
mediano ta m a n o . 

El Proceso Unificadode Rational es un modelodel proceso moderno ygenerico que se organ iza en fases (illi- 
cit), elaboracion, construccionytransicion), pero que separa las actividades (requerimientos, analisisydise- 
no, etc.) de estasfases. 

• La tecnologi'a CASE proporciona ayuda automatizada a los procesos del software. Las herramientas CASE ayu- 
dan a las actividades Individuals del proceso; los bancos de trabajo ayudan a un conjunto de actividades re- 
lacionadas; tos entornos ayudan a todas o a la mayor in de las actividades del proceso del software. 



LECTURAS ADICIONALES H M A 1^- LA I I ll J L \/ I I I\/l ISA O I 

Extreme Programming Explained: Embrace Change. Unlibroevangelicoquedescribeelprocesoylasexperiencias 
de la programacion extrema . El autorfue el inventorde la programacion extrema ycomunica in uy bien su entusias- 
mo. (Kent Beck, 2000, Addison-Wesley.) 

The Rational Unified Process-An Intruduction. Este era el trabajo m a sinteresantedisponiblesobreRUPcuandose 
estaba escribiendo este libro. Krutchen describe bien el proceso, pero se echa en falta una exposicion m as d eta 1 1 a - 
da de las dificultades practicas que presenta su uso. (P. Krutchen, 2000, Addison-Wesley. ) 

Managing Software Qualityand Business Risk. Este esprincipalmenteun libro sob re la gestlon del software, pero 
incluye un capi'tulo excelente (Capitulo 4) sobre los modelos de proceso. (M. Ould, 1999, John Witey & Sons.) 

«Aclassification ofCASE technology ». El esq u e ma de clasificacion propuesto en estearticulo se ha utilizado en este 
capi'tulo, pero Fuggetta entra en mas detalle e ilustra comovarios productos comerciales encajan en este esquema. 
[A. Fuggetta, /EEE Computer, 26 (12), diciembre de 1993.1 



ejercicios mHMIHMiaMW 

41 Sugiera el modelo de proceso del software generico que podria utilizarse para gestionarel desarrollo de los 
siguientes sistemas, dando algunas razones basadas en el tipo de sistema a desarrollar: 

• Un sistema de control antibloqueo de frenos de un automovil. 

• Un sistema de realidad virtual para ayudar al mantenimiento del software. 

• Un sistema de contabilidad universitaria que reemplace el existente. 

Un sistema interactivo que permita a los pasajeros encontrar los horarios de los trenes a partir de laster- 
minales instaladas en las estaciones. 
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42 Explique por que los programas que se desarrollan utilizando el desarrollo evolutivo tienden a ser dificiles 
de mantener. 

43 Explique como el modelo en cascada para el proceso del software y el de construccion de prototipos pue- 
den encajar en el de proceso en espiral. 

44 ^Cuales son las ventajas de proporcionar vistas estaticasy dinamicas del proceso del software como en el 
Proceso Unificado de Rational? 

45 Explique por que es importante hacer distincion entre el desarrollo de los requerimientos del usuario y el 
de los requerimientos del sistema en el proceso de ingenieria de requerimientos. 

46 Describa las principales actividades en el proceso de diseno del software y las salidas de estas actividades. 
Utilizando un diagrama, muestre las posibles relaciones entre las salidas. 

47 iCuales son los cinco componentes de un metodo de diseno? Considere cualquier metodo que conozca y 
describa sus componentes. Evalue la integridad del metodo elegido. 

48 Disefie un modelo de proceso para las pruebas de ejecucion y recopile los resultados. 

49 Explique por que un sistema software que se utiliza en un entorno real debe cambiar o convertirse progre- 
sivamente en menos util. 

410 Indique como el esquema de clasificacion de la tecnologia CASE puede serutil para los administradores en- 
cargados de adquirir sistemas CASE. 

411 Haga un estudio de las herramientas disponibles en su entorno local de desarrollo y clasifiquelas de acuer- 
do con los parametros (funcion, actividad, amplitud de soporte) sugeridos aqui . 

412 Historicamente, la introduccion de la tecnologia ha causado profundos cambios en el mercado laboral y, al 
menos temporalmente, elimina personas de los puestos de trabajo. Comente si es probable que la introduc- 
cion de tecnologia CASE avanzada pueda tener las mismas consecuencias para los ingenieros de software. 
Si piensa que no es asi, explique por que no. Si piensa que reducira (as oportunidades de trabajo, ^es etico 
para los ingenieros afectados resistirse, pasivamente o activamente, a la introduccion de esta tecnologia? 
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Gestion 

de proyectos 



Objetivos 

El objetivo de este capitulo es dar un panorama de la gestion de 
proyectos de software. Cuando termine de leer este capitulo: 

• conocera las tareas principales de los gestores de proyectos 
de software. 

• comprendera por que la naturaleza del software hace mas 
dificil la gestion de proyectos software que la gestion de los 
proyectos de otras ingenienas. 

• comprendera por que planificar proyectos es esencial en todos 
los proyectos de software. 

• conocera la forma en que las representaciones graficas 
(graficos de barras y redes de actividades) son utilizadas por 
los gestores de proyectos para representar las agendas del 
proyecto. 

• conocera el proceso de gestion de riesgos y algunos de los 
riesgos que surgen en los proyectos de software. 

Contenidos 

5.1 Actividades de gestion 

5.2 Planificacion del proyecto 

5.3 Calendarizacion del proyecto 

5.4 Gestion de riesgos 



86 



CAPITULO 5 • Gestion de proyectos 



La gestion de proyectos de software es una parte esencial de la ingenieriadel software. Labue- 
na gestion no puede garantizar el exito del proyecto. Sin embargo, la mala gestionusualmen- 
te lleva al fracaso del proyecto. El software es entregado tarde, los costes son mayores que los 
estimados y los requerimientos no se cumplen. 

Los gestores de software son responsables de la planificacion y temporalizacion del desa- 
rrollo de los proyectos. Supervisan el trabajo para asegurar que se lleva a cabo conforme a los 
estandares requeridos y supervisan el progreso para comprobar que el desarrollo se ajusta al 
tiempo previsto y al presupuesto. La administracion de proyectos de software es necesaria de- 
bido a que la ingenieria de software profesional siempre esta sujeta a restricciones organiza- 
cionales de tiempo y presupuesto. El trabajo del gestor de proyectos de software es asegurar 
que estos cumplan dichas restricciones y entregar software que contribuya a las metas de la 
compania de desarrollo software. 

Los gestores de software hacen el mismo tipo de trabajo que otros gestores. Sin embargo, 
la ingenieria del software es diferente en varios aspectos a otros tipos, lo que hace a la ges- 
tion de software particularmente dificil. Algunas de estas diferencias son las siguientes: 

1. Elproducto es intangible. El gestor de un proyecto de construccion de un embarca- 
dero o de uno de ingenieria civil puede ver el producto mientras se esta desarrollando. 
Si hay un desfase en calendario, el efecto en el producto es visible de forma obvia: par- 
tes de la estructura no estan completas. El software es intangible. No se puede ver ni 
tocar. Los gestores de proyectos de software no pueden ver el progreso. Confian en 
otros para elaborar la documentacion necesaria para revisar el progreso. 

2. No existen procesos del software estdndar. En las disciplinas de ingenieria con larga 
historia, el proceso se prueba y verifica. Para tipos particulares de sistemas, como 
puentes o edificios, el proceso de ingenieria se comprende bien. Sin embargo, los pro- 
cesos de software varian notablemente de una organizacion a otra. A pesar de que la 
comprension del proceso del software se ha desarrollado de forma significativa en los 
ultimos anos, aun no se puede predecir con certezacuandoun proceso particular tien- 
de a desarrollar problemas. Esto es especialmente cierto cuando el proyecto software 
es parte un proyecto de ingenieria de un sistema grande. 

3. A menudo los proyectos grandes son unicos. Por lo general, los proyectos grandes de 
software son diferentes de proyectos previos. En consecuencia, los gestores, aun cuan- 
do cuenten con una amplia experiencia, esta no es suficiente para anticipar los pro- 
blemas. Mas aun, los rapidos cambios tecnologicos en las computadoras y las comu- 
nicaciones hacen parecer obsoleta la experiencia previa. Las lecciones aprendidas en 
esas experiencias pueden no ser transferibles a los nuevos proyectos. 

Debido a estos problemas, no es sorprendente que algunos proyectos de software se retra- 
sen, sobrepasen el presupuesto y se entreguen fuera de tiempo. A menudo, los sistemas de 
software son nuevos y tecnologicamente innovadores. Frecuentemente los proyectos de in- 
genieria innovadores (como los nuevos sistemas de transporte) tambien tienen problemas de 
temporalizacion. Dadas las mezclas de dificultades, es notable que muchos proyectos de soft- 
ware sean entregados a tiempo y segun lo presupuestado. 

La gestion de proyectos de software es un tema amplio y no puede tratarse en un solo 
capitulo. Por lo tanto, en este capitulo se introduce el tema y se describen tres actividades 
importantes de gestion: planificacion, calendarizacion de proyectos y gestion de riesgos. 
Los ultimos capitulos (en la Parte 6) tratan otros aspectos de la gestion de software, entre 
los que se incluyen la gestion de personal, la estimacion de los costes de software y la ges- 
tion de la calidad. 
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Actividades de gestion 

Es imposible redactar una descripcion estandar del trabajo de un gestor de software. El tra- 
bajo difiere enormemente dependiendo de la organizacion y del producto de software a desa- 
rrollar. Sin embargo, en algun momento, muchos gestores son responsables de algunas o de 
la totalidad de las siguientes actividades: 

• Redaccion de lapropuesta 

• Planificacion y calendarizacion del proyecto 

• Estimacion de costes del proyecto 

• Supervision y revision del proyecto 

• Seleccion y evaluacion del personal 

• Redaccion y presentacion de informes 

La primera etapa de un proyecto de software implica redactar una propuesta para realizar 
ese proyecto. La propuesta describe los objetivos del proyecto y como se llevaria a cabo. Por 
lo general, incluye estimaciones de coste y tiempo y justifica por que el contrato del proyec- 
to se le debe dar a una organizacion o a un equipo en particular. La redaccion de la propues- 
ta es una tarea critica, ya que la existencia de muchas organizaciones de software depende de 
las propuestas aceptadas y los contratos asignados. No existen guias para esta tarea; la redac- 
cion de propuestas es una habilidad que se adquiere con la practica y la experiencia. 

La planificacion de proyectos se refiere a la identificacion de actividades, hitos y entregas 
de un proyecto. Por lo tanto, se debe bosquejar un plan para guiar el desarrollo hacia las me- 
tas del proyecto. La estimacion del coste es una actividad relacionada con la estimacion de 
los recursos requeridos para llevar a cabo el plan del proyecto. Este aspecto se tratara con ma- 
yor detalle mas adelante en este capitulo y en el Capitulo 26. 

La supervision de proyecto es una actividad continua. El gestor debe tener conocimiento 
del progreso del proyecto y comparar el progreso con los costes actuales y los planificados. 
Aunque muchas organizaciones tienen mecanismos formales para supervisar, un gestor habil 
podria formarse una imagen clara de lo que pasa llevando a cabo una entrevista informal con 
el personal del proyecto. 

La supervision informal predice problemas importantes del proyecto, y revela dificultades 
que pueden aparecer. Por ejemplo, las entrevistas diarias con el personal del proyecto pueden 
exteriorizar un problema en un fallo del software. Mas que esperar un informe de atraso del 
proyecto, el gestor de software podria asignar algun experto para resolver el problema o po- 
dria decidir si se vuelve a programar. 

Durante un proyecto, es normal tener varias revisiones formales de su gestion. Se hace 
la revision completa del progreso y de los desarrollos tecnicos del proyecto, y se tiene en 
cuenta el estado del proyecto junto con los propositos de la organizacion que ha encargado 
el software. 

El resultado de una revision puede dar lugar a la cancelacion del proyecto. El tiempo de 
desarrollo para un proyecto grande de software puede ser de varios anos. Durante ese tiempo 
los objetivos organizacionales tienden obviamente a cambiar. Estos cambios pueden signifi- 
car que el software ya no se necesita o que los requerimientos originales del proyecto son ina- 
propiados. La gestion puede decidir parar el desarrollo del software o cambiar el proyecto para 
adecuarlo a los cambios de los objetivos de la organizacion. 

Por lo general, los gestores de proyectos tienen que seleccionar a las personas para traba- 
jar en su proyecto. De forma ideal, habra personal disponible con habilidades y experiencia 
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apropiada para trabajar en el proyecto. Sin embargo, en muchos casos, los gestores tienen que 
establecer un equipo ideal minimo para el proyecto. Las razones que explican esto son: 

1 . El presupuesto del proyecto no cubre la contratacion de personal con sueldos altos. Se 
tiene que contratar personal con menos experiencia y menor sueldo. 

2. El personal con experiencia apropiada no esta disponible dentro o fuera de la organi- 
zacion. Es imposible reclutar nuevo personal para el proyecto. Dentro de la organiza- 
cion, los mejores trabajadores ya se han asignado a otros proyectos. 

3. Laorganizaciondeseadesarrollarlas habilidades de sus empleados. El personal inex- 
perto puede ser asignado al proyecto para aprender y adquirir experiencia. 

El gestor de software tiene que trabajar con estas restricciones al seleccionar al personal 
del proyecto. Sin embargo, todos estos problemas son probables a menos que exista un miem- 
bro del proyecto que cuente con algo de experiencia en el tipo de sistema a desarrollar. Sin 
esta experiencia, probablemente se cometeran muchos errores pequenos . En el Capitulo 25 se 
abordara la formacion del equipo de desarrollo y la seleccion del personal. 

Los gestores del proyecto son responsables de informar a los clientes y contratistas sobre 
el proyecto. Tienen que redactar documentos concisos y coherentes que resuman la informa- 
cion critica de los informes detallados del proyecto. Les debe ser posible presentar esta in- 
formacion durante las revisiones de progreso. En consecuencia, comunicarse efectivamente 
de forma oral y escrita es una habilidad esencial que un gestor de proyectos debe tener. 

52 Planificacion del proyecto 

La gestion efectiva de un proyecto de software depende de planificar completamente el pro- 
greso del proyecto. El gestor del proyecto debe anticiparse a los problemas que puedan sur- 
gir, asi como preparar soluciones a esos problemas. Un plan, preparado al inicio de un pro- 
yecto, debe utilizarse como un conductor para el proyecto. Este plan inicial debe ser el mejor 
posible de acuerdo con la informacion disponible. Este evolucionara conforme el proyecto 
progrese y la informacion sea mejor. 

En la Seccion 5.2.1 se describe una estructura para un plan de desarrollo de software. Ademas 
de un plan del proyecto, los gestores tienen que preparar otros tipos de planes, los cuales se des- 
criben brevemente en la Figura 5.1 y seran tratados con mas detalle en otros capitulos del libro. 





Plan d« csltdsd 


Describe los procedimientos y los estandares de calidad que se uti lizard n en un pro- 
yecto. Vease el Capftulo 24. 


Plan de validation 


Describe el enfoque, los recursos y la programation utitizados para la validaci6n del 
sistema. 


Plan de gestion de configuradones 


Describe los procedimientos para la gestion de configuradones y las estructuras a 
utilizer. Vease et Capftulo 29. 


Plan de mantenimiento 


Predke los requerimientos del mantenimiento del sistema, los costes del manteni- 
miento y el esfueizo requerido. Vease el Capftulo 27. 


Plan de desarrollo del personal 


Describe como se desarrotlart las habilidades y experiencia de los miembros del 
equipo del proyecto. 

Figura 5.1 Tipos de plan. 
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Establecer las restricciones del proyecto 
Hacerlavaloracidn inicial de los parametros del proyecto 
Definir los hitos del proyecto y productos a entregar 
Mlentras el proyecto no se haya completado o cancelado repetlr 
Bosquejar la programacion en el tiempo del proyecto 
Iniciar actividades acordescon la programacion 
Esperar (por un momento) 
Revisar el progreso del proyecto 

Revisar las estimaciones de los parametros del provecto 
Actualizarla programacion del proyecto 

Renegociar las restricciones del proyecto y los productos a entregar 
Si (surgen problemas) entonces 

Iniciar la revision tecnica y la posible revision 
fin de si 
fin de repetir 

El pseudocodigo que se muestra en la Figura 5.2 describe el proceso de planificacion del 
proyecto para el desarrollo de software. Muestra que la planificacion es un proceso iterativo 
que solamente se completa cuando el proyecto mismo se termina. Conforme la informacion 
se hace disponible, el plan debe revisarse regularmente. Las metas globales del negocio son 
un factor importante que debe considerarse cuando se formula el plan del proyecto. Confor- 
me estas cambien, seran necesarios cambios en el proyecto. 

El proceso de planificacion se inicia con una valoracion de las restricciones que afectan al 
proyecto (fecha de entrega requerida, personal disponible, presupuesto global, etcetera). Esta 
se lleva a cabo en conjunto con una estimacion de los parametros del proyecto, como su es- 
tructura, tamano y distribucion de funciones. Entonces se definen los hitos de progreso y pro- 
ductos a entregar. En ese momento, el proceso entra en un ciclo. Se prepara un calendario para 
el proyecto y las actividades definidas en el calendario se inician o se continuan. Despues de 
algun tiempo (por lo general 2 o 3 semanas), se revisa el proyecto y se senalan las discrepan- 
cias. Debido a que las estimaciones iniciales de los parametros del proyecto son aproxima- 
ciones, el plan siempre debera actualizarse. 

Cuando se dispone de mas informacion, los gestores del proyecto revisan las suposiciones 
del proyecto y la agenda. Si el proyecto se retrasa, tienen que renegociar con el cliente las res- 
tricciones del mismo y las entregas. Si esta renegociacion no tiene exito y no se puede cum- 
plir el calendario, se debe llevar a cabo una revision tecnica. El objetivo de esta revision es 
encontrar un enfoque alternativo que se ajuste a las restricciones del proyecto y cumpla con 
las metas del calendario. 

Por supuesto, los gestores de proyectos inteligentes no suponen que todo ira bien. Duran- 
te el proyecto siempre surgen problemas en algunas descripciones. Las suposiciones iniciales 
y el calendario deben ser mas bien pesimistas que optimistas. Debe haber suficiente holgura 
para que las contingencias en el plan, las restricciones del proyecto y los hitos no se tengan 
que negociar cada vez que se efectua un ciclo en el plan. 

5.2.1 El plan del proyecto 

El plan del proyecto fija los recursos disponibles, divide el trabajo y crea un calendario de tra- 
bajo. En algunas organizaciones, el plan del proyecto es un unico documento que incluye to- 
dos ios diferentes tipos de planes (Figura 5.1). En otros casos, este plan solo se refiere al pro- 
ceso de desarrollo. Otros pueden estar referenciados, pero son proporcionados por separado. 



Figura 5.2 

Planificacion del 
proyecto. 
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El plan que se describe aqiri tiene que ver con el ultimo tipo de plan mencionado. Los de- 
talles de este plan varian dependiendo del tipo de proyecto y de la organizacion. Sin embar- 
go, muchos planes incluyen las siguientes secciones: 

1 . Introduction. Describe brevemente los objetivos del proyecto y expone las restriccio- 
nes (por ejemplo, presupuesto, tiempo, etcetera) que afectan a la gestion del proyecto. 

2. Organization del proyecto. Describe la forma en que el equipo de desarrollo esta or- 
ganizado, la gente involucrada y sus roles en el equipo. 

3 . Andlisis de riesgo. Describe los posibles riesgos del proyecto, la probabilidad de que 
surjan estos riesgos y las estrategias de reduccion de riesgos propuestas. La gestion de 
riesgos se estudia en la Seccion 5.4. 

4. Requerimientos de recursos de hardware y software. Describe el hardware y el soft- 
ware de ayuda requeridos para llevar a cabo el desarrollo. Si es necesario comprar 
hardware, se deben incluir las estimaciones de los precios y las fechas de entrega. 

5. Division del trabajo. Describe la division del proyecto en actividades e identifica los 
hitos y productos a entregar asociados con cada actividad. En la Seccion 5.2.2 se in- 
dican los hitos y productos a entregar. 

6. Programa del proyecto. Describe las dependencias entre actividades, el tiempo esti- 
mado requerido para alcanzar cada hito y la asignacion de la gente a las actividades. 

7. Mecanismos de supervision e informe. Describe la gestion de informes y cuando de- 
ben producirse, asi como los mecanismos de supervision del proyecto a utilizar. 

El plan del proyecto debe revisarse regularmente durante el proyecto. Algunas partes, 
como el calendario del proyecto, cambiaran frecuentemente; otras seran mas estables. Para 
simplificarlas revisiones, se debe organizar el documento en secciones separadas que permi- 
tan su reemplazo de forma individual conforme evoluciona el plan. 

5.2.2 Hitos y entregas 

Los gestores necesitan informacion para hacer su trabajo. Como el software es intangible, esta 
informacion solo se puede proveer como documentos que describan el estado del software que 
se esta desarrollando. Sin esta informacion, es imposible juzgar el progreso y no se pueden 
actualizar los costes y calendarios. 

Cuando se planifica un proyecto, se debe establecer una serie de hitos — puntos finales de 
una actividad del proceso del software — . En cada uno, debe existir una salida formal, como 
un informe, que se debe presentar al gestor. Los informes de hitos no deben ser documentos 
amplios. Deben ser informes cortos de los logros en una actividad del proyecto. Los hitos de- 
ben representar el fin de una etapa logica en el proyecto. Los hitos indefinidos como «80 % 
del codigo completo» son imposibles de validar y carecen de utilidad para la gestion del pro- 
yecto. No podemos validar si se ha llegado a esta etapa debido a que la cantidad de codigo 
que se tiene que desarrollar no es precisa. 

Una entrega es el resultado del proyecto que se entrega al cliente. De forma general, se en- 
trega al final de una fase principal del proyecto como la especificacion, el diseno, etcetera. 
Como regla general, las entregas son hitos, pero estos no son necesariamente entregas. Dichos 
hitos pueden ser resultados internos del proyecto que son utilizados por el gestor del proyec- 
to para verificar el progreso del mismo pero que no se entregan al cliente. 

Para establecer los hitos, el proceso del software debe dividirse en actividades basicas con 
sus salidas asociadas. Por ejemplo, la Figura 5.3 muestra las actividades involucradas en la 
especificacion de requerimientos cuando se utiliza la construccion de prototipos para ayudar 
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ACTIVIDADES 



CEstudio AnAlisis de Desarrollo Estudio A_^/Especificaci6n de\ 

de viabilidad 1 Wequerimientos t)\. de prototipos 1 *"\. del disefto J l requerimientos J 



Informe | 


Requerimientos 




■ 

Informe 


Diseno | 


Requerimientos 


de viabilidad 1 


de usuarios 




de evaiuacibn 


arquitect6nico | 


del sistema 



HITOS 

Figura 5.3 Hitos del proceso de especif Icaclon de requerimientos. 



a validar dichos requerimientos. Tambien se muestran las salidas principales de cada activi- 
dad (los hitos del proyecto). Las entregas del proyecto, las cuales son entregadas al cliente, 
son la definicion y especificacion de requerimientos. 



53 Calendarizacion del proyecto 

Esta es una de las tareas mas dificiles para los gestores de proyectos. Los gestores estiman el 
tiempo y los recursos requeridos para completar las actividades y organizarias en una suce- 
sion coherente. A menos que el proyecto a calendarizar sea similar a otro anterior, las esti- 
maciones previas son una base incierta para la calendarizacion del nuevo proyecto. La esti- 
macion del calendario se complica mas por el hecho de que proyectos diferentes pueden 
utilizar metodos de diseno y lenguajes de implementacion diferentes. 

Si el proyecto es tecnicamente complejo, las estimaciones iniciales casi siempre son opti- 
mistas aun cuando los gestores traten de considerar las eventualidades. A este respecto, la ca- 
lendarizacion del tiempo para la creacion del software no es diferente a la de cualquier otro 
tipo de proyecto grande y complejo. Los nuevos aeroplanos, los puentes e incluso los nuevos 
modelos de automoviles se retrasan debido a problemas no anticipados. Por lo tanto, los ca- 
lendarios se deben actualizar continuamente en la medida que se disponga de mejor informa- 
cion acerca del progreso. 

La calendarizacion del proyecto (vease la Figura 5.4} implica separar todo el trabajo de un 
proyecto en actividades complementarias y considerar el tiempo requerido para completar di- 
chas actividades. Por lo general, algunas de estas se llevan a cabo en paralelo. Debemos co- 
ordinar estas actividades paralelas y organizar el trabajo para que la mano de obra se utilice 
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Figura 5.4 El proceso de calendarizacibn del proyecto. 
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de forma optima. Deben evitarse situaciones en que el proyecto entero se retrase debido a que 
no se ha terminado una actividad critica. 

Normalmente, las actividades del proyecto deben durarpor lo menos una semana. Hacer sub- 
divisiones mas finas significa invertir una cantidad desproporcionada de tiempo en la estima- 
cion y revision de tablas. Tambien es Ml asignar una cantidad de tiempo maxima de 8 a 10 se- 
manas para realizar cualquier actividad. Si lleva mas tiempo, se deben hacer subdivisiones. 

AI estimar la calendarizacion, los gestores no deben suponer que cada etapa del proyecto 
estara libre de problemas. Las personas que trabajan en el pueden enfermarse o renunciar, el 
hardware puede fallar y el software o hardware de soporte puede llegar tarde. Si el proyecto 
es nuevo y tecnicamente complejo, ciertas partes podrian ser mas complicadas y llevarian mas 
tiempo del que se estimo originalmente. 

Como en los calendarios, los gestores deben estimar los recursos necesarios para comple- 
tarcada tarea. El recurso principal es el esfuerzo humano que se requiere. Otros recursos pue- 
den ser el espacio en disco requerido en un servidor, el tiempo requerido de hardware espe- 
cializado, un simulador o el presupuesto para viajes del personal del proyecto. En el 
Capitulo 26 se trata con mayor detalle este tema. 

Una buena regla practica es estimar como si nada fuera a salir mal, y entonces incremen- 
tar la estimacion para abarcar los problemas previstos. Con este mismo fin, a la estimacion se 
le debe agregarun factor de contingencia adicional. Este factor extra de contingencia depen- 
de del tipo de proyecto, de los parametros del proceso (fecha de entrega, estandares, etcete- 
ra) y de la calidad y experiencia de los ingenieros de software que trabajen en el proyecto. 
Como regla, para los problemas previstos siempre debe agregarse un 30 % a la estimacion ori- 
ginal y otro 20 % para cubrir algunas cosas no previstas. 

Por lo general, el calendario del proyecto se representa como un conjunto de graficos 
que muestran la division del trabajo, las dependencias de las actividades y la asignacion del 
personal. Esto se aborda en la siguiente seccion. Por lo general, las herramientas de ges- 
tion de software, como Microsoft Project, se utilizan para automatizar la produccion de 
diagramas. 

5.3.1 Graficos de barras y redes de actividades 

Los graficos de barras y las redes de actividades son notaciones graficas que se utilizan para 
ilustrar la calendarizacion del proyecto. Los graficos de barras muestran quien es responsa- 
ble de cada actividad y cuando debe comenzar y finalizar esta. Las redes de actividades mues- 
tran las dependencias entre las diferentes actividades que conforman un proyecto. Los grafi- 
cos de barras y las redes de actividades se generan automaticamente a partir de una base de 
datos de la informacion del proyecto utilizando una herramienta de gestion de proyectos. 

Considere el conjunto de actividades que se muestra en la Figura 5.5. Esta tabla recoge 
las tareas, la duracion e interdependencias de estas. En ella se observa que la Tarea T3 de- 
pende de la Tarea TI. Esto significa que TI debe completarse antes de que comience T3. 
Por ejemplo, TI podria ser la preparacion de un diseno de un componente y T3 la imple- 
mentaciondeese diseno. Antes deque se inicie laimplementacion, el diseno debe estar ter- 
minado. 

Dadas la dependencia y la duracion estimada de las actividades, una red de actividades 
muestra la sucesion de actividades que deben generarse (vease la Figura 5.6). Esta muestra 
que actividades se llevan a cabo en paralelo y cuales deben ejecutarse en secuencia debido a 
la dependencia con una actividad previa. Las actividades se representan como rectangulos ; los 
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Figura 5.5 Duracion 
y dependencias 
de las tareas. 
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hitos y las entregas se muestran con esquinas redondeadas. Las fechas en este grafico mues- 
tran la fecha de inicio de la actividad (estan escritas en estilo britanico, en el cual el dia pre- 
cede al mes). La red se debe leer de izquierda a derecha y de arriba abajo. 

En la herramienta de gestion de proyecto utilizada para elaborar este grafico, todas las ac- 
tividades deben terminar en hitos. Una comienza cuando su hito precedente (puede depender 
de varias actividades) se ha alcanzado. Por lo tanto, en la tercera columna la Figura 5.5 se 
muestra el hito correspondiente (por ejemplo, M5) que se alcanza cuando las tareas en esa co- 
lumna terminan (vease la Figura 5.6). 

Antes de que se pueda pasar de un hito a otro, todas las trayectorias deben completarse. 
Por ejemplo, la tarea T9, que se muestra en la Figura 5.6, no se puede iniciar hasta que las ta- 
reas T3 y T6 se terminen. 



Figura 5.6 Una red 
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El tiempo minimo requerido para finalizar el proyecto se estima teniendo en cuenta la tra- 
yectoria mas larga en la red de actividades (el camino critico). En este caso, es 1 1 semanas de 
tiempo transcurrido o 55 dias laborales. En la Figura 5.6 el camino critico se muestra como 
una sucesion de rectangulos mas resaltados. El calendario completo del proyecto depende de 
dicho camino. Cualquier aplazamiento al completar una actividad critica provoca retraso en 
el proyecto, ya que las actividades siguientes no pueden comenzar hasta que se finalice la ac- 
tividad retrasada. 

Sin embargo, los retrasos de las actividades que no estan ligadas al camino critico no provo- 
can necesariamente un aplazamiento en todo el calendario. Mientras los retrasos no se propaguen 
a estas actividades como para que se exceda el tiempo total del camino critico, el proyecto no se 
vera afectado. Por ejemplo, si T8 se retrasa, esto no afectara a la fecha final de terminacion del 
proyecto puesto que no se encuentra sobre el camino critico. El grafico de barras (vease la Figu- 
ra 5.7) del proyecto muestra la holgura de los posibles retrasos como barras sombreadas. 

Los gestores tambien utilizan las redes de actividades para asignar los trabajos en el pro- 
yecto. Dichas redes pueden dar una percepcion de la dependencia de las actividades que de 
forma intuitiva no son obvias. Es posible modificar el disefio del sistema de tal forma que se 
acorte al camino critico. El calendario del proyecto se puede acortar debido a que se reduce 
la cantidad de tiempo de espera para finalizar las actividades. 

Inevitablemente, las agendas del proyecto iniciales seran incorrectas. A medidaque el pro- 
yecto se desarrolla, las estimaciones deben ser comparadas con los tiempos reales. Esta com- 
paracion puede ser utilizada como base para una revision de la agenda de las siguientes par- 
tes del proyecto. Cuando se muestran los tiempos reales, debemos revisar el grafico de 
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actividades. Las actividades siguientes del proyecto pueden ser reorganizadas para reducir la 
duracion del camino critico. 

La Figura 5.7 es una forma alternativa de representar la informacion del calendario del pro- 
yecto. Es un grafico de barras (algunas veces llamado grafico de Gantt, su inventor) que 
muestra el calendario de un proyecto y las fechas iniciales y finales de las actividades. Algu- 
nas de las actividades que se muestran en la Figura 5.7 son seguidas por una barra sombrea- 
da cuya longitud es calculada por una herramienta de calendarizacion. Esto muestra que exis- 
te alguna flexibilidad en las fechas de terminacion de estas actividades. Si alguna de estas no 
se completa a tiempo, el camino critico no se vera afectado hasta el final del periodo marca- 
do por la barra sombreada. Las actividades que caen sobre dicho camino no tienen margen de 
error y se distinguen por no tener asociada una barra sombreada. 

Ademas de considerar la calendarizacion, los gestores de proyectos tambien deben tener 
en cuenta la asignacion de recursos y, en particular, la asignacion de personal a las activida- 
des del proyecto. Esta asignacion puede ser introducida tambien desde las herramientas de 
gestion de proyectos, y los graficos de barras generados muestran el personal del proyecto (Fi- 
gura 5.8). Las personas no tienen por que estar asignadas al proyecto en todo momento. Du- 
rante diferentes periodos pueden estar de vacaciones, trabajando en otros proyectos, en cur- 
sos de formacion o realizando otras actividades. 

Por lo general, las grandes organizaciones emplean varios especialistas para que trabajen 
en el proyecto cuando sea necesario. En la Figura 5.8 se puede ver que Mary y Jim son espe- 
cialistas que solo trabajan en una actividad del proyecto. Esto puede provocar problemas en 
la calendarizacion. Si un proyecto se retrasa mientras un especialista trabaja en el, puede cau- 
sar efectos contundentes en los otros proyectos. Estos proyectos seran retrasados ya que el es- 
pecialista no estara disponible. 



5.4 Gestion de riesgos 



Una tarea importante del gestor de proyectos es anticipar los riesgos que podrian afectar a la 
programacion del proyecto o a la calidad del software a desarrollar y emprender acciones para 
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evitar esos riesgos. Los resultados de este analisis de riesgos se deben documentar a lo largo 
del plan del proyecto junto con el analisis de consecuencias cuando el riesgo ocurra. Identi- 
ficar estos y crear planes para minimizar sus efectos en el proyecto se llama gestion de ries- 
gos (Hall, 1998; Ould, 1999). 

De forma simple, se puede concebir un riesgo como una probabilidad de que una circuns- 
tancia adversa ocurra. Los riesgos son una amenaza para el proyecto, para el software que se 
esta desarrollando y para la organizacion. Estas categorias de riesgos se definen como se 
muestra a continuacion: 

1. Riesgos del proyecto. Estos afectan la calendarizacion o los recursos del proyecto. Un 
ejemplo podria ser la perdida de un disenador experimentado. 

2. Riesgos del producto. Estos afectan a la calidad o al rendimiento del software que se 
esta desarrollando. Un ejemplo podria ser que el rendimiento en un componente que 
hemos comprado sea menor que el esperado. 

3. Riesgos del negocio. Estos afectan a la organizacion que desarrolla o suministra el soft- 
ware. Por ejemplo, que un competidor introduzca un nuevo producto es un riesgo de 
negocio. 

Por supuesto, estos tipos no son exclusivos entre si. Si un programador experto abandona 
el proyecto, esto es un riesgo para el proyecto (debido a que la entrega del sistema se puede 
retrasar), para el producto (debido a que un sustituto puede no ser tan experto y cometer mu- 
chos errores) y para el negocio (debido a que esa experiencia puede no contribuir a negocios 
futures). 

Los riesgos que pueden afectar a un proyecto dependen del propio proyecto y del entorno 
organizacion al donde se desarrolla. Sin embargo, muchos riesgos son universales. La 
Figura 5.9 muestra algunos de estos riesgos. 

La gestion de riesgos es importante particularmente para los proyectos de software debi- 
do a las incertidumbres inherentes con las que se enfrentan muchos proyectos. Estas incerti- 
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de la herramienta CASE 


Producto 


Las herramientas CASE que ayudan al proyecto no tienen el 
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Figura 5.9 Posibles riesgos del software. 
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dumbres son el resultado de los requerimientos ambiguamente definidos, las dificultades en 
la estimacion de tiempos y los recursos para el desarrollo del software, la dependencia en las 
habilidades individuales, y los cambios en los requerimientos debidos a los cambios en las ne- 
cesidades del cliente. Es preciso anticiparse a los riesgos: comprender el impacto de estos en 
el proyecto, en el producto y en el negocio, y considerar los pasos para evitarlos. En el caso 
de que ocurran, se deben crear planes de contingencia para que sea posible aplicar acciones 
de recuperacion. 

La Figura 5.10 muestra el proceso de gestion de riesgos. Este comprende varias etapas: 

1. identification de riesgos. Identificar los posibles riesgos para el proyecto, el produc- 
to y los negocios. 

2. Andlisis de riesgos. Valorar las probabilidades y consecuencias de estos riesgos. 

3. Planificacion de riesgos. Crear planes para abordar los riesgos, ya sea para evitarlos 
o minimizar sus efectos en el proyecto. 

4. Supervision de riesgos. Valorar los riesgos de forma constante y revisar los planes 
para la mitigacion de riesgos tan pronto como la informacion de los riesgos este dis- 
ponible. 

El proceso de gestion de riesgos, como otros de planificacion de proyectos, es un proceso 
iterativo que se aplica a lo largo de todo el proyecto. Una vez que se genera un conjunto de 
planes iniciales, se supervisa lasituacion. Encuanto surjamas informacion acercade los ries- 
gos, estos deben analizarse nuevamente y se deben establecer nuevas prioridades. La preven- 
cion de riesgos y los planes de contingencia se deben modificar tan pronto como surja nueva 
informacion de los riesgos. 

Los resultados del proceso de gestion de riesgos se deben documentar en un plan de ges- 
tion de riesgos. Este debe incluir un estudio de los riesgos a los que se enfrenta el proyecto, 
un analisis de estos y los planes requeridos para su gestion. Si es necesario, puede incluir al- 
gunos resultados de la gestion de riesgos; porejemplo, planes especificos de contingencia que 
se activan si aparecen dichos riesgos. 



5.4.1 Identification de riesgos 

Esta es la primera etapa de la gestion de riesgos. Comprende el descubrimiento de los posi- 
bles riesgos del proyecto. En principio, no hay que valorarlos o darles prioridad en esta etapa 
aunque, en la practica, por lo general no se consideran los riesgos con consecuencias meno- 
res o con baja probabilidad. 

Esta identificacion se puede llevaracabo a traves de un proceso de grupo utilizando un en- 
foque de tormenta de ideas o simplemente puede basarse en la experiencia. Para ayudar al pro- 
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ceso, se utiliza una lista de posibles tipos de riesgos. Hay al menos seis tipos de riesgos que 
pueden aparecer: 

1. Riesgos de tecnologia. Se derivan de las tecnologias de software o de hardware utili- 
zadas en el sistema que se esta desarrollando. 

2. Riesgos de personal. Riesgos asociados con las personas del equipo de desarrollo. 

3. Riesgos organizacionales. Se derivan del entorno organizacional donde el software se 
esta desarrollando. 

4. Riesgos de herramientas. Se derivan de herramientas C A S E y de otro software de apo- 
yo utilizado para desarrollar el sistema. 

5. Riesgos de requerimientos. Se derivan de los cambios de los requerimientos del clien- 
te y el proceso de gestionar dicho cambio. 

6. Riesgos de estimation. Se derivan de los estimados administrativos de las caracteris- 
ticas del sistema y los recursos requeridos para construir dicho sistema. 

La Figura 5.11 proporciona algunos ejemplos de riesgos posibles en cada una de estas ca- 
tegorias. El resultado de este proceso debe ser una larga lista de riesgos que podrian presen- 
tarse y afectar al producto, al proceso o al negocio. 



5.4.2 Analisis de riesgos 

Durante este proceso, se considera por separado cada riesgo identificado y se decide acerca 
de la probabilidad y la seriedad del mismo. No existe una forma facil de hacer esto — recae 
en la opinion y experiencia del gestor del proyecto — . No se hace una valoracion con nume- 
ros precisos sino en intervalos: 

• La probabilidad del riesgo se puede valorar como muy bajo (< 1 0%), bajo ( 1 0-25%), mo- 
derado (25-50%), alto (50-75%) o muy alto (>75%). 

• Los efectos del riesgo pueden ser valorados como catastrofico, serio, tolerable o insig- 
nificante. 





Tecnologia 


La base de dates que se utiliza en el sistema no puede procesar muchas transacciones por segundo 
como se esperaba. 

Us comoonentes de software que deben reutilizarse contienen defectos que imitan su tuntionalidad 


Personal 


Es imposrble redutar personal con las habWdades requeridas para el proyecto. 
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Herramientas 


Es ineficiente el cottigo generado por las herramientas CASE 
Las hermrnientas CASE no se pueden integrar. 
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Se proponen cambios en los requerimientos que requieren rehacer el dbefio. 
Los cfientes no comprenden d impacto de los cambios en los requerimientos. 


Estimation 


El tiempo requerido para desarrollar el software esta subestimado. 
La tasa de reparacton de defectos est! subesttmada. 
El tamano del software esti subestimado. 



Figura 5.11 Riesgos y tipos de riesgos. 
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El resultado de este proceso de analisis se debe colocar en una tabla, la cual debe estar or- 
denada segun la seriedad del riesgo. La Figura 5.12 ilustraesto para los riesgos identificados 
en la Figura 5.11. Obviamente, aqui es arbitraria la valoracion de la probabilidad y seriedad. 
En la practica, para hacer esta valoracion se necesita informacion detallada del proyecto, el 
proceso, el equipo de desarrollo y la organizacion. 

Por supuesto, tanto la probabilidad como la valoracion de los efectos de un riesgo cambian 
conforme se disponga de mayor informacion acerca del riesgo y los planes de gestion del mis- 
mo se implementen. Por lo tanto, esta tabla se debe actualizar durante cada iteracion del pro- 
ceso de riesgos. 

Una vez que los riesgos se hayan analizado y clasificado, se debe discernir cuales son los 
mas importantes que se deben considerar durante el proyecto. Este discernimiento debe de- 
pender de una combinacion de la probabilidad de aparicion del riesgo y de los efectos del mis- 
mo. En general, siempre se deben tener en cuenta todos los riesgos catastroficos, asi como to- 
dos los riesgos serios que tienen mas que una moderada probabilidad de ocurrir. 

Boehm (Boehm, 1988) recomienda identificary supervisar los «10 riesgos mas altos», pero 
este numero parece demasiado arbitrario. El numero exacto de riesgos a supervisar debe de- 
pender del proyecto. Pueden ser cinco o 15. No obstante, el numero apropiado debe ser ma- 
nejable. Un numero muy grande de riesgos requiere obtenermucha informacion. De los ries- 
gos identificados en la Figura 5.12, conviene considerar los ocho que tienen consecuencias 
serias o catastroficas. 
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Figura 5.12 Analisis de riesgos. 
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5.4.3 Planlflcaclon de rlesgos 

El proceso de planificacion de riesgos considera cada uno de los riesgos clave que han sido 
identificados, asi como las estrategias para gestionarlos. Otra vez, no existe un proceso sen- 
cillo que nos permita establecer los planes de gestion de riesgos. Depende del juicio y de la 
experiencia del gestordel proyecto. La Figura 5.13 muestra posibles estrategias para los ries- 
gos que han sido identificados en la Figura 5.12. Estas estrategias seguidas pueden dividirse 
entrescategorias. 

1. Estrategias de prevention. Siguiendo estas estrategias, la probabilidad de que el ries- 
go aparezca se reduce. Un ejemplo de este tipo de estrategias es la estrategia de evita- 
cion de defectos en componentes de la Figura 5.13. 

2 . Estrategias de minimization. Siguiendo estas estrategias se reducira el impacto del ries- 
go. Un ejemplo de esto es la estrategia frente a enfermedad del personal de la Figura 5.13. 

3 . Planes de contingencia. Seguir estas estrategias es estar preparado para lo peor y te- 
ner una estrategia para cada caso. Un ejemplo de este tipo de estrategia es el mostra- 
do en la Figura 5.13 con la estrategia para problemas financieros. 

Puede verse aqui una analogia con las estrategias utilizadas en sistemas criticos para ase- 
gurar fiabilidad, proteccion y seguridad. Basicamente, es mejor usar una estrategia para evi- 
tar el riesgo. Si esto no es posible, utilizar una para reducir los efectos serios de los riesgos. 
Finalmente, tener estrategias para reducir el impacto del riesgo en el proyecto y en el producto. 

5.4.4 Supervision de riesgos 

La supervision de riesgos normalmente valora cada uno de los riesgos identificados para de- 
cidir si este es mas o menos probable y si han cambiado sus efectos. Por supuesto, esto no se 
puede observar de forma directa, por lo que se tienen que buscar otros factores para dar indi- 
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Figura 5.13 Estrategia de gestion de riesgos. 
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cios de la probabilidad del riesgo y sus efectos. Obviamente, estos factores dependen de los 
tipos de riesgo. La Figura 5.14 da algunos ejemplos de los factores que ayudan en la valora- 
cion de estos tipos de riesgos. 

La supervision de riesgos debe ser un proceso continuo y, en cada revision del progreso de 
gestion, cada uno de los riesgos clave debe ser considerado y analizado por separado. 





Tecnologia 


Entrega retrasada del hardware o de la ayuda al software, muchos problemas tecnologicos 
reportados. 


Personal 


Baja moral del personal, malas relaciones entre los miembros del equipo, disponibilidad de 
empleo. 


Organ iza donal 


Chismorreo organiiacional, falta de acciones por el gestor principal. 


Herramientas 


Rechazo de los miembros del equipo para utilizar herramientas, quejas acerca de las herra- 
mientas CASE, peticiones de estaciones de trabajo mis potentes. 


Requerimientos 


Peticiones de muchos cambios en los requerimientos, quejas del cliente. 


Estimacidn 


Fracaso en el cumplimiento de los tiempos acordados, y en la eliminacion de defectos re- 
portados. 

Figura 5.14 Factores de riesgo. 



PUNTOS CLAVE 

• Es esencial una buena gestion de proyectos de software para que los proyectos de ingeniena de software se 
desarrollen a tiempo ysegun presupuesto. 

• La gestion de proyectos de software es diferente a ta gestion de otro tipo de ingenienas. El software es in- 
tangible. Los proyectos pueden ser nuevos o innovadores, por lo que no existe un conjunto de experiencias 
para guiar su gestion. El proceso del software no se comprende del todo. 

• Los gestores de software tienen diversos papeles. Sus actividades mas significativas son la planif icacidn, es- 
timacidn y calendarizacidn de los proyectos. La planificacidn y la estimacidn son procesos iterativos. Tienen 
continuidad a lo largo del proyecto. En cuantosetenga mas informacion.se deben revisar los planes ycalen- 
darios. 

• Un hito de un proyecto es el resultado predecible de una actividad en el que se debe presentar un informe del 
progreso a la gestion. Los hitos ocurren de forma frecuente en un proyecto de software. Una entrega es un hito 
que se entrega al cliente del proyecto. 

• La calendarizacidn de proyectos implica la creacidn de varias representaciones graficas de partes del plan del 
proyecto. Estas incluyen redes de actividades que muestran las interrelaciones de las actividades del proyec- 
to y graficos de barras que muestran la duracidn de dichas actividades. 

• Se deben identificar y valorar los riesgos mayores del proyecto para establecer su probabilidad y consecuen- 
cias para este. En cuanto a los riesgos mas probables y potencialmente serios, se deben hacer planes para 
anularlos, gestionarlos o tratarlos. Estos riesgos se deben analizar de manera explicita en cada reunion del 
progreso del proyecto. 
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LECTURAS COM PLEM ETARIAS 



Waltzing with Bears: Managing Risk on Software Projects. Una introduction muy practicayfacil de leersobre ries- 
gos y su gestion. (T. DeMarcoyT. Lister, 2003, Dorset House.) 

Managing Software Quality and Business Risk. El Capitulo 3 de este libro essencillamente el mejor estudio de rles- 
gos que se haya visto. El libro se orienta a estos y es probablemente el mejor libro de este tema disponible en el me- 
mento de esta redaccion. (M. Ould, 1999, John Wiley and Sons.) 

The Mythical Man Month. Los problemas de la gestion de software no ban cambiado desde los anos 60 y este es uno 
de los mejores librossobre el tema. Una recopilacion interesante y legible de la gestion de uno de los primeros gran- 
des proyectos de software, el sistema operativo IBM OS/360. La segunda edicion incluye otros a rticu los clasicos de 
Brooks. (F. P. Brooks, 1975, Addison-Wesley.) 

Software Project Survival Guide. Una explicacion muy pragmatica sobre gestion de software, pero que contiene unos 
buenos consejos. Es facil de leery entender. (S. McConneil, 1998, Microsoft Press.) 

Vease la Parte 6 para otras lecturas sobre gestion. 



EJERCICIOS 



&1 Explique por que la intangibilidad de los sistemas de software plantea problemas para la gestion de pro- 
yectos de software. 

52. Explique por que los mejores programadores no siempre son los mejores gestores de software. La res- 
puesta puede tener como base la lista de actividades de gestion dadas en (a Seccidn 5.1. 

53 Explique por que el proceso de planif icacion de proyectos es iterativoy por que un plan se debe revisarcon- 
tinuamente durante el proyecto de software. 

54 Explique brevemente el propdsito de cada una de las secciones en un plan de proyecto de software. 

55 tCual es la diferencia fundamental entre un hito y una entrega? 

5.6 La Figura 5.15 muestra un conjunto de actividades, duraciones y dependencias. Disene una red de activida- 
des y un grafico de barras que muestren la programacion del proyecto. 

57 La Figura 5.5 sehala la duracion de las tareas para las actividades del proyecto de software. Suponga que 
hay un serio retraso no anticipado y que en lugar de requerir 10 dias, la tarea T5 requiere 40 dias. Revise la 
red de actividades resultante, resaltando el nuevo camino critico. Disene un nuevo grafico de barras que 
muestre como se podria reorganizar el proyecto. 

58 Utilizando las instancias referidas en la literatura para los problemas en los proyectos, haga una lista de las 
dificultadesde gestion en esos proyectos de ca I endarizaci on fallidos. (Comience con el libro de Brooks, su- 
gerido en la seccidn de lecturas complementarias.) 

59 Ademas de los riesgos que se muestran en la Figura 5.11, identifique otros seis posibles riesgos en los pro- 
yectos de software. 
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Figura 5.15 

Duracion y 
dependencias 
de las tareas. 




5.10 Los contratos de precio prefijado, donde el contratista ofrece un precio fijo para completar el sistema, pue- 
den ser utilizados para traspasar los riesgos del proyecto del cliente al contratista. Si algo va mal, el con- 
tratista asumira la diferencia. Indique de que modo el uso de contratos puede incrementar la probabilidad 
de la aparicion de riesgos. 

5.11 Su jefe le ha solicitado que entregue un software en un tiempo que solo puede ser posible cumplir pregun- 
tando al equipo del proyecto sj desea trabajar horas extras sin pago alguno. Todos los miembros del equi- 
po tienen hijos pequeflos. Comente si deberia aceptar estapeticion de sujefe o si deberiapersuadiral equi- 
po para dar su tiempo a la organizacion mas que a sus familias. ^Que factores podrian ser significativos en 
la decision? 

5.12 Como programador, se le ofrece un ascenso como gestor de proyecto, pero su sensacion es que puede te- 
ner una contribucion mas efectiva en un papel tecnico que en uno administrativo. Comente cuando deberia 
aceptar ese ascenso. 



Capftulo 6 Requerimientos del software 

Capftulo 7 Proceso de la ingeniena de requerimientos 

Capftulo 8 Modelos de sistemas 

Capftulo 9 Especificacion de sistemas cn'ticos 

Capftulo 10 Especificacion formal 



Tal vez el principal problema al que nos enfrentamos en el desarrollo de sistemas gran- 
des y complejos es el de la ingenieria de requerimientos. Esta trata de establecer lo que 
el sistema debe hacer, sus propiedades emergentes deseadas y esenciales, y las restric- 
ciones en el funcionamiento del sistema y los procesos de desarrollo del software. Por 
lo tanto puede considerar la ingenieria de requerimientos como el proceso de comuni- 
cacion entre los clientes y usuarios del software y los desarrolladores del mismo. 

La ingenieria de requerimientos no es simplemente un proceso tecnico. Los requeri- 
mientos del sistema estan inf luenciados por las preferencias, aversiones y prejuicios de 
los usuarios y por cuestiones politicas y organizacionales. Estas con caracteristicas fun- 
damentals humanas, y las nuevas tecnologias, como los casos de uso, los escenarios y 
los metodosformales, no nos ayudan mucho en la resolucion de estos problemasespi- 
nosos. 

Los capitulos de esta seccion se dividen en dos clases -en los Capitulos 6 y 7 intro- 
duzcolosfundamentosdela ingenieria de requerimientos, y en los Capitulos 8 a lOdes- 
cribo los modelos y tecnicas utilizados en el proceso de ingenieria de requerimientos. 
Mas especificamente: 

1. El Capitulo 6 trata sobre los requerimientos del software y los documentos de re- 
querimientos. Se considera que se entiende por requerimiento, los diferentes tl- 
pos de requerimientos y como estos requerimientos se organizan en un docu- 
mento de especificacion de requerimientos. En este tema se introduce el segundo 
caso de estudio, un sistema de biblioteca. 

2. El Capitulo 7 se centra en las actividades en el proceso de ingenieria de requeri- 
mientos; como los estudios de viabilidad siempre deben ser parte de la ingenie- 
ria de requerimientos, de las tecnicas para la obtencidn y analisis de requeri- 
mientos, y de la validacion de requerimientos. Debido a que los requerimientos 
inevitablementecambian,tambienseabordael im porta nte tema de la gestion de 
requerimientos. 

3. El Capitulo 8 describe los tipos de modelos de sistemas que se pueden desarro- 
llar en el proceso de ingenieria de requerimientos. Estos proporcionan una des- 
cripcion mas detail, id a a los desabolladores del sistema. Aqui el entasis esta en 
el modeladoorientadoaobjetosperotambienincluyounadescripciondelos dia- 
gram as deflujo de da tos. Se considera que estos son intuit ivosy utiles, especial- 
mente para darle una imagen de como la informacion es procesada por un sis- 
tema desde el principio hasta el final. 

4. El entasis en los Capitulos 9 y 10 esta en la especif icacion de los sistemas critlcos. 
El Capitulo 9 aborda la especificacion de las propiedades de confiabilidad emer- 
gentes. Describe los enfoques dirigidos por riesgos yasuntosde la especificacion 
de la seguridad, la habilidad y la proteccion. En el Capitulo 10, se introducen las 
tecnicas de especificacion formal. Los metodos formales han tenido menos Im- 
pacto del que se predijo, pero cada vez se utilizan mas en la especificacion de la 
seguridad y de los sistemas de mision critlcos. Aborda tanto los enfoques alge- 
braicos como los basados en modelos en este capitulo. 
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Objetivos 

Los objetivos de este capitulo son presentar los requerimientos de 
sistemas software y explicar las diferentes formas de expresar los 
requerimientos del software. Cuando haya leido este capitulo: 

• entendera los conceptos de requerimientos del usuario y del 
sistema y por que estos requerimientos se deben escribir de 
diferentes formas; 

• entendera las diferencias entre los requerimientos del 
software funcionales y no funcionales; 

• entendera como los requerimientos se pueden organizar en un 
documento de requerimientos del software. 

Contenidos 

6. 1 Requerimientos funcionales y no funcionales 

6.2 Requerimientos del usuario 

6.3 Requerimientos del sistema 

6.4 Especificacion de la jnterfaz 

6.5 El documento de requerimientos del software 
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Los requerimientos para un sistema son la descripcion de los servicios proporcionados porel 
sistemay sus restricciones operativas. Estos requerimientos reflejan las necesidades de los clien- 
tes de un sistema que ayude a resolver algun problema como el control de un dispositivo, hacer 
un pedido o encontrar informacion. El proceso de descubrir, analizar, documentary verificar es- 
tos servicios y restricciones se denomina ingenieria de requerimientos (RE). Este capitulo se 
centra en dichos requerimientos y como describirlos. En el Capitulo 4 se dio una introduccion 
al proceso de ingenieria de requerimientos y en el Capitulo 7 se analizara con mas detalle. 

El termino requerimiento no se utiliza de una forma constante en la industria de software. 
En algunos casos, un requerimiento es simplemente una declaracion abstractade alto nivel de 
un servicio que debe proporcionar el sistema o una restriccion de este. En el otro extremo, es 
una definicion detallada y formal de una funcion del sistema. Davis (Davis, 1993) explica por 
que existen estas diferencias: 

Si una compaiiia desea establecer un contrato para un proyecto de desarrollo de software 
grande, debe definir sus necesidades de una forma suficientemente abstracta para establecer a 
partir de ella una solucion. Los requerimientos deben redactarse de tal forma que varios contra- 
ristas pueden licitar el contrato, ofreciendo, quizas, formas diferentes de cumplir las necesida- 
des de los clientes en la organizacion. Una vez que el contrato se asigna, el contratista debe re* 
dactar una definicion del sistema para el cliente mas detalladamente de forma que este 
comprenda y pueda validar lo que hara el software. Ambos documentos se pueden denominar 
documento de requerimientos para el sistema. 

Algunos de los problemas que surgen durante el proceso de ingenieria de requerimientos 
son resultado de no hacer una clara separacion entre estos diferentes niveles de descripcion. 
Aqui se distinguen utilizando la denominacion requerimientos del usuario para designar los 
requerimientos abstractos de alto nivel, y requerimientos del sistema para designar la des- 
cripcion detallada de lo que el sistema debe hacer. Los requerimientos del usuario y del sis- 
tema se pueden definir como se muestra a continuacion: 

1 . Los requerimientos del usuario son declaraciones, en lenguaje natural y en diagramas, 
de los servicios que se espera que el sistema proporcione y de las restricciones bajo 
las cuales debe funcionar. 

2. Los requerimientos del sistema establecen con detalle las funciones, servicios y res- 
tricciones operativas del sistema. El documento de requerimientos del sistema (algu- 
nas veces denominado especificacion funcional) debe ser preciso. Debe definir exac- 
tamente que es lo que se va a implementar. Puede ser parte del contrato entre el 
comprador del sistema y los desarrolladores del software. 

Diferentes niveles de especificacion del sistema son de utilidad debido a que comunican 
la informacion del sistema a diferentes tipos de lectores. La Figura 6.1 ilustra la distincion en- 
tre los requerimientos del usuario y del sistema. Este ejemplo de un sistema de biblioteca 
muestra la manera en que un requerimiento del usuario se expande en varios requerimientos 
del sistema. Puede verse en la Figura 6.1 que el requerimiento del usuario es mas abstracto, 
y que los requerimientos del sistema anaden detalle, explicando los servicios y funciones que 
deben ser proporcionados por el sistema a desarrollar. 

Es necesario redactar los requerimientos en diversos niveles de detalle debido a que dife- 
rentes tipos de lectores los utilizan de distinta manera. La Figura 6.2 muestra los tipos de lec- 
tores de los requerimientos de usuario y del sistema. Los lectores de los requerimientos de 
usuario normalmente no tratan de como se implementara el sistema y pueden ser administra- 
dores que no estan interesados en los recursos detallados del sistema. Los lectores de los re- 
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Definici6n del requerimiento del usuario 



1. LIBSYS controlari todos los datos requeridos por las agendas que 
licencian los derechos de autor en el Reino Unido y en otra parte. 



Especificari6n de los requerimientos del sistema 

1.1 Al hacer una petici6n de un documento del LIBSYS, el solicitante se 
presentard con un formulario que registre los detalles del usuario y 
de la petiti6n hecha. 

1.2 El formulario de peticibn del LIBSYS sera almacenado en el sistema 
durante cinco anos desde la fecha de la peticibn. 

1 .3 Todos los formularios de peticiones del LIBSYS se deben indexar por 
usuario, por el nombre del material solicitado y por el proveedor de 
la petici6n. 

1 .4 El LIBSYS mantendra un fichero en el que se registraran todas las 
peticiones que se han hecho al sistema. 

1 .5 Para el material donde se aplican los derechos de prestamo del 
autor, los detalles del prestamo serin enviados mensualmente a las 
agendas que licencian los derechos de autor que se han registrado 
con LIBYSS. 



querimientos del sistema necesitan saber con mas precision que hara el sistema debido a que 
estan interesados en como ayudara esto a los procesos de negocio o debido a que estan im- 
plicados en la implementacion del sistema. 



Requerimientos funcionales y no funcionales 



A menudo, los requerimientos de sistemas software se clasifican en funcionales y no funcio- 
nales, o como requerimientos del dominio: 

1 . Requerimientos funcionales. Son declaraciones de los servicios que debe proporcio- 
nar el sistema, de la manera en que este debe reaccionar a entradas particulares y de 
como se debe comportar en situaciones particulares. En algunos casos, los requeri- 
mientos funcionales de los sistemas tambienpueden declararexplicitamente loque el 
sistema no debe hacer. 

2. Requerimientos no funcionales. Son restricciones de los servicios o funciones ofreci- 
dos por el sistema. Incluyen restricciones de tiempo, sobre el proceso de desarrollo y 



Requerimientos 
del usuario 



Administradores clientes 
Usuarios finales del sistema 
Ingenieros clientes 
Administradores contratistas 
Arquitectos del sistema 




Usuarios finales del sistema 
Ingenieros clientes 
Arquitectos del sistema 
Desarrolladores del software 
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estandares. Los requerimientos no funcionales a menudo se aplican al sistema en su 
totalidad. Normalmente apenas se aplican a caracteristicas o servicios individuales del 
sistema. 

3. Requerimientos del dotninio. Son requerimientos que provienen del dominio de apli- 
cacion del sistema y que reflejan las caracteristicas y restricciones de ese dominio. 
Pueden ser funcionales o no funcionales. 

En realidad, la distincion entre diferentes tipos de requerimientos no es tan clara como su- 
gieren estas definiciones. Por ejemplo, un requerimiento del usuario sobre seguridad podria 
parecer un requerimiento no funcional. Sin embargo, cuando se desarrolla en detalle, puede 
generarotros requerimientos que son claramente funcionales, como la necesidad de incluiren 
el sistema recursos para la autentificacion del usuario. 



6.1.1 Requerimientos funcionales 
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puede mostrar documentos en diferentes formatos; la intencion de este requerimiento es que 
los visores para todos estos formatos esten disponibles. Sin embargo, el requerimiento esta 
ambiguamente redactado; no clarifica que se deben proporcionar los visores de cada forma- 
to. Un desarrolladorbajo lapresion del tiempo sencillamente podria proporcionar un visor de 
texto y afirmar que se ha cumplido el requerimiento. 

En principio, la especificacion de requerimientos funcionales de un sistema debe estar 
completa y ser consistente. La completitud significaque todos los servicios solicitados porel 
usuario deben estar definidos. La consistencia significa que los requerimientos no deben te- 
ner definiciones contradictorias. En la practica, para sistemas grandes y complejos, es practi- 
camente imposible alcanzar los requerimientos de consistencia y completitud. 

Una razon de esto es que es facil cometer errores y omisiones cuando se redactan especi- 
ficaciones para sistemas grandes y complejos. Otra razon es que los stakeholders del sistema 
(vease el Capitulo 7) tienen necesidades diferentes, y a menudo contradictorias. Estas con- 
tradicciones pueden no ser obvias cuando los requerimientos se especifican por primera vez, 
por lo que se incluyen requerimientos contradictorios en la especificacion. Es posible que los 
problemas surjan solamente despues de un analisis mas profundo o, a veces, despues de que 
se termine el desarrollo y el sistema se entregue al cliente. 

6.1.2 Requerimientos no funcionales 

Los requerimientos no funcionales, como su nombre sugiere, son aquellos requerimientos que 
no se refieren directamente a las funciones especificas que proporciona el sistema, sino a las 
propiedades emergentes de este como la fiabilidad, el tiempo de respuesta y la capacidad de 
almacenamiento. De forma alternativa, definen las restricciones del sistema como la capaci- 
dad de los dispositivos de entrada/salida y las representaciones de datos que se utilizan en las 
interfaces del sistema. 

Los requerimientos no funcionales rara vez se asocian con caracteristicas particulares del 
sistema. Mas bien, estos requerimientos especifican o restringen las propiedades emergen- 
tes del sistema, como se explico en el Capitulo 2. Por lo tanto, pueden especificar el rendi- 
miento del sistema, la proteccion, la disponibilidad, y otras propiedades emergentes. Esto 
significa que a menudo son mas criticos que los requerimientos funcionales particulares. 
Los usuarios del sistema normalmente pueden encontrar formas de trabajar alrededor de una 
funcion del sistema que realmente no cumple sus necesidades. Sin embargo, el incumpli- 
miento de un requerimiento no funcional puede significar que el sistema entero sea inutili- 
zable. Por ejemplo, si un sistema de vuelo no cumple sus requerimientos de fiabilidad, no 
se certificara como seguro para el funcionamiento; si un sistema de control de tiempo real 
no cumple sus requerimientos de rendimiento, las funciones de control no funcionaran co- 
rrectamente. 

Los requerimientos no funcionales no solo se refieren al sistema software a desarrollar. 
Algunos de estos requerimientos pueden restringir el proceso que se debe utilizar para 
desarrollar el sistema. Ejemplos de requerimientos de procesos son la especificacion de los 
estandares de calidad que se deben utilizar en el proceso, una especificacion que el dise- 
no debe producir con una herramienta C A S E particular y una descripcion del proceso a se- 
guir. 

Los requerimientos no funcionales surgen de las necesidades del usuario, debido a las res- 
tricciones en el presupuesto, a las politicas de la organizacion, a la necesidad de interoperabili- 
dad con otros sistemas software o hardware, o a factores extemos como regulaciones de segu- 
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Figura 6.3 Tipos de requerimientos no fundonales. 



ridad o legislaciones sobre privacidad. La Figura 6.3 es unaclasificacionde los requerimientos 
no funcionales. Puede verse en este diagrama que los requerimientos no funcionales pueden ve- 
nirde las caracteristicas requeridas del software (requerimientos del producto), de laorganiza- 
cion que desarrolla el software (requerimientos organizacionales) o de ftientes externas. 
Los tipos de requerimientos no funcionales son: 

1 . Requerimientos del producto. Estos requerimientos especifican el comportamiento 
del producto. Algunos ejemplos son los requerimientos de rendimiento en la rapidez 
de ejecucion del sistema y cuanta memoria se requiere; los requerimientos de fiabili- 
dad que fijan la tasa de fallos para que el sistema sea aceptable; los requerimientos de 
portabilidad, y los requerimientos de usabilidad. 

2. Requerimientos organizacionales. Estos requerimientos se derivan de politicas y pro- 
cedimientos existentes en la organizacion del cliente y en la del desarrollador. Algu- 
nos ejemplos son los estandares en los procesos que deben utilizarse; los requeri- 
mientos de implementacion, como los lenguajes de programacion o el metodo de 
diseno a utilizar, y los requerimientos de entrega que especifican cuando se entregara 
el producto y su documentacion. 

3. Requerimientos externos. Este gran apartado incluye todos los requerimientos que se 
derivan de los factores externos al sistema y de su proceso de desarrollo. Estos pue- 
den incluir los requerimientos de interoperabilidad que definen la manera en que el sis- 
tema interactua con sistemas de otras organizaciones; los requerimientos legislatives 
que deben seguirse para asegurar que el sistema funcione dentro de la ley, y los re- 
querimientos eticos. Estos ultimos son puestos en un sistema para asegurar que sera 
aceptado por sus usuarios y por el publico en general. 



La Figura 6.4 muestra ejemplos de requerimientos del producto, organizacionales y exter- 
nos tornados del sistema de biblioteca LIBS YS cuyos requerimientos del usuario se analiza- 
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Raque rtailento del pf sdkicto 

ai La interfaz de usuario del UBSYS se jmplementara como HTML simple sin marcos o ap- 
plets Java. 

BiqinrimlwUi uigaiiliatioiial 

932 El proceso de desarrollo del sistema y los documentos a entregar deberan ajustarse al 
proceso y a los productos a entregar def inidos en XYZCo-SP-STAN-95. 

Requerimiento estenio 

10.6 El sistema no debera revelar al personal de la biblioteca que lo utilice ninguna infor- 
macion personal de los usuarios del sistema aparte de su nombre y numero de referenda de 
la biblioteca. 



ron en la Seccion 6.1.1. El requerimiento del producto restringe la libertad de los disenado- 
res del LIBS YS en la implementacion de la interfaz de usuario del sistema. No dice nadaacer- 
ca de la funcionalidad del LIBSYS e identifica claramente una restriccion del sistema mas que 
una funcion. Se incluye este requerimiento debido a que simplifica el problema de asegurar 
que el sistema funcione con navegadores diferentes. 

El requerimiento organizacional especifica que el sistema se debe desarrollar conforme a 
un proceso estandar de la compania definido como XYZCo-SP-STAN-95 . El requerimiento 
externo se deriva de la necesidad del sistema de cumplir la legislacion sobre privacidad. Es- 
pecifica que no se debe permitir al personal de la biblioteca el acceso a datos, como la direc- 
cion de los usuarios del sistema, que no necesitan para realizar su trabajo. 

Un problema comun con los requerimientos no funcionales es que pueden ser dificiles de 
verificar. Los usuarios o clientes declaran a menudo estos requerimientos como metas gene- 
rales tales como la facilidad de uso, la capacidad del sistema para recuperarse de los fallos o 
la respuesta rapida al usuario. Estas metas imprecisas causan problemas a los desarrolladores 
del sistema puesto que dejan abierta la posibilidad a interpretacion, lo que provoca discusio- 
nes subsecuentes una vez que el sistema se entrega. Como ilustracion de este problema, con- 
sidere la Figura 6.5. Esta figura muestra una meta del sistema que se refiere a la usabilidad de 
un sistema de control del trafico aereo y es tipico de como un usuario puede expresar los re- 
querimientos de usabilidad. Se ha reescrito para mostrar la manera en que la meta se puede 
expresar como un requerimiento no funcional que se pueda probar. Aunque es imposible ve- 
rificar objetivamente la meta del sistema, se pueden disefiar pruebas del sistema para contar 
los errores cometidos por los controladores utilizando un simulador del sistema. 

Siempre que sea posible, se deben redactar los requerimientos funcionales de manera 
cuantitativa para que se puedan probar de un modo objetivo. La Figura 6.6 muestra varias me- 
tricas posibles que pueden usarse para especificar las propiedades no funcionales del sistema. 
Se pueden medir estas caracteristicas cuando se prueba el sistema para comprobar si cumple 
sus requerimientos no funcionales. 

Une meta del 

Debe ser facil para tos controladores experimentados utilizar el sistema y se debe organizar de 
tal modo que se minimicen los errores del usuaria 

Un requerimiento mo funcional verif ica ble 

Despues de unaf ormacion de dos horas, a los controladores experimentados les debera ser po- 
sible utilizar todas las funciones del sistema. Despues de esta f ormacion, la media de errores 
cometidos por tos usuarios experimentados no excedera de dos por dfa. 



Figura 6.4 Ejemplos 
requerimientos no 
funcionales. 



Figura 6.5 Metas 
de! sistema y 
requerimientos 
verifi cables. 
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Rapidez Transacdones procesadas por segundo. 

Tiempo de respuesta al usuario y a eventos 
Tiempo de actualizactfn de la pantalla 



Figura 6.6 Metricas 
para especificar 
requerimientos no 
funcionales. 



TamaAo 


KBytes 




Numero de chips de RAM 


Facilidad de uso 


Tiempo de formad6n 




Numero de cuadros de ayuda 


Fiabilidad 


Tiempo medio entre fallos 




Probabitidad de no disponibilidad 




Tasa de oairrenda de fallos 




Disponibilidad 


Robustei 


Tiempo de reinicio despues de fallos 




Porcentaje de eventos que provocan fallos 




Probabitidad de corruption de los datos despues de fallos 



Portabilidad 



Porcentaje de dedaraciones dependientes del objetivo 
Numero de sistemas objetivo 



En lapractica, sin embargo, los clientes deun sistemapueden encontrarpracticamente im- 
posible traducir sus metas en requerimientos cuantitativos. Para algunas metas, como las de 
mantenibilidad, no existen metricas que se puedanutilizar. En otros casos, aun cuando seapo- 
sible la especificacion cuantitativa, es posible que los clientes no puedan relacionar sus nece- 
sidades con estas especificaciones. No entienden lo que significa un cierto numero que defi- 
ne la fiabilidad requerida (por ejemplo) en funcion de su experiencia diaria con los sistemas 
informaticos. Ademas, el coste de verificar de forma objetiva los requerimientos no funcio- 
nales cuantitativos puede ser muy alto, y los clientes que pagan el sistema quizas piensen que 
estos costes no son justificados. 

Por lo tanto, los documentos de los requerimientos a menudo incluyen las declaraciones 
de las metas mezcladas con los requerimientos. Dichas metas pueden ser utiles para los desa- 
rrolladores puesto que dan idea de las prioridades del cliente. Sin embargo, siempre se les debe 
advertirque estan abiertas a interpretaciones erroneas y que no se pueden verificar de forma 
objetiva. 

A menudo, los requerimientos no funcionales entran en conflicto e interactuan con otros 
requerimientos funcionales o no funcionales. Por ejemplo, puede haber un requerimiento 
que especifique que la capacidad maxima de memoria utilizada por un sistema no debe ser 
mayor de 4 Mbytes. Las restricciones de memoria son comunes en los sistemas embebidos 
donde el espacio y el peso estan limitadosy se debe minimizarel numero de chips de ROM 
que almacenan el sistema software. Otro requerimiento podria ser que el sistema debe co- 
dificarse utilizando Ada, un lenguaje de programacion para el desarrollo de software criti- 
co de tiempo real. Sin embargo, puede que no sea posible compilarcon menos de 4 Mbytes 
un programa en Ada con la funcionalidad requerida. Por lo tanto, tiene que haber un equi- 
libro entre estos requerimientos: un lenguaje alternativo de desarrollo o un aumento en la 
memoria del sistema. 

Es de utilidad diferenciar los requerimientos funcionales y no funcionales en el documen- 
to de requerimientos. En la practica, esto es dificil. Si los requerimientos no funcionales se 
declaran de forma separada de los funcionales, algunas veces es dificil ver la relacion entre 
ellos. Si se declaran con los requerimientos funcionales, puede resultar dificil separar las con- 
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Figura 6.7 Un 

requerimiento del 
dominio obtenido de 
un sistema de 
proteccion de trenes. 
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racion del tren. La terminologia utilizada es especifica del dominio. Para entenderla, se ne- 
cesitaunaciertacomprensiondel funcionamiento del sistema ferroviario y las caracteristi- 
cas de los trenes. 

El requerimiento para el sistema de trenes ilustra el problema principal con los requeri- 
mientos del dominio. Estos se escriben en el lenguaje del dominio de aplicacion (ecuaciones 
matematicas en este caso), y a menudo es dificil de comprender por los ingenieros de soft- 
ware. Los expertos en el dominio pueden dejar fuera de un requerimiento informacion senci- 
llamente porque para ellos es obvia. Sin embargo, puede no serlo para los desarrolladores del 
sistema y, por lo tanto, es posible que implementen el requerimiento de forma equivocada. 

6.2 Requerimientos del usuario 

Los requerimientos del usuario para un sistema deben describir los requerimientos funciona- 
les y no funcionales de tal forma que sean comprensibles por los usuarios del sistema sin co- 
nocimiento tecnico detallado. Unicamente deben especificar el comportamiento externo del 
sistema y deben evitar, tanto como sea posible, las caracteristicas de diseno del sistema. Por 
consiguiente, si se estan redactando requerimientos del usuario, no se debe utilizar jerga del 
software, notaciones estructuradas o formales, o describir los requerimientos por la descrip- 
cion de la implementacion del sistema. Deben redactarse en un lenguaje sencillo, con tablas 
y formularios sencillos y diagramas intuitivos. 

Sin embargo, pueden surgir diversos problemas cuando se redactan con frases del lengua- 
je natural en un documento de texto: 

1 . Falta de claridad. Algunas veces es dificil utilizar el lenguaje de forma precisa y no 
ambigua sin hacer el documento poco conciso y dificil de leer. 

2. Confusion de requerimientos. No se distinguen claramente los requerimientos funcio- 
nales y no funcionales, las metas del sistema y la informacion para el diseno. 

3- Conjuncion de requerimientos. Diversos requerimientos diferentes se pueden expre- 
sar de forma conjunta como un unico requerimiento. 

Para ilustrar algunos de estos problemas, considere uno de los requerimientos para la bi- 
blioteca que se muestran en la Figura 6.8. 

Este requerimiento incluye tanto informacion conceptual como detallada. Expresa que 
debe hacer un sistema de contabilidad como una parte inherente del LIB S Y S . Sin embargo, 
tambien incluye el detalle de que el sistema de contabilidad debe admitir descuentos para los 
usuarios habituales del LIBS YS . Este detalle podriaubicarse mejor en la especificacion de re- 
querimientos del sistema. 

Es una buena practica separar en el documento de requerimientos los requerimientos del 
usuario de los detallados del sistema. Por otra parte, los lectores no tecnicos de los requeri- 
mientos del usuario se pueden confundir con detalles que solo son relevantes a los lectores 
tecnicos. La Figura 6.9 ilustra esta confusion. Este ejemplo se ha tornado de un documento 
de requerimientos real para una herramienta CASE para editar modelos de diseno de software. 

43 B UBSVS proporcionar* un JUUIala da tentobadaJ «randera que mantendra registro 
de toate lo* pagos hadlot por los usu" 

dan tunugurar este sistema de forma que los ueuarlol habituales puedan reclblr un preclo 
rebajado. 



Figura 6.8 Un 

requerimiento 
de usuario para un 
sistema de 
contabilidad 
en el LIBSYS. 
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2.6 Recursos de la cuadricula. Para ayudar a la ublcaclon de entidades en un dlagrama, el usua- 
rio puede acttvar una cuadricula en centfmetros o en pulgadas, medlante una opclon enelpand 
de control. Al princlplo, la cuadricula esta desactivada. Esta cuadricula se puede actlvar o desacti- 
Flgura 6 9 Un var en cualquler momento durante una seslon de edlclon y poner en pulgadas y centfmetros. La 

re uerimiento de opclon de cuadricula se proporclonara en la vista de reducclon de ajuste, pero el numero de If- 

' 1 neas de la cuadricula a mostrarse reduclra para evltar saturar et dlagrama mas pequeno con If- 

usuario para un . . 

neas de cuaoncuia. 

editorde cuadricula. 



El usuario puede especificar que se debe mostrar una cuadricula para que las entidades se co- 
loquen de forma precisa en un diagrama. 

La primera frase mezcla tres diferentes clases de requerimientos. 

1. Un requerimiento funcional conceptual que establece que el sistema de edicion debe 
proporcionar una cuadricula. Sepresentalajustificacionde esto. 

2. Un requerimiento no funcional que proporciona informacion detallada de las unida- 
des de la cuadricula (centimetros o pulgadas). 

3. Un requerimiento de interfaz de usuario no funcional que define la manera en que la 
cuadricula es activada o desactivada por el usuario. 

El requerimiento de la Figura 6.9 tambien muestra una parte de la informacion de inicia- 
lizacion. Define que la cuadricula esta inicialmente desactivada. Sin embargo, no define sus 
unidades cuando se activa. Proporciona alguna informacion detallada — como la de inter- 
cambiar las unidades, pero no el espaciado entre las lineas de la cuadricula. 

Los requerimientos del usuario que incluyen demasiada informacion restringen la libertad 
del desarrollador del sistema para proporcionar soluciones innovadoras a los problemas del 
usuario y son dificiles de comprender. Los requerimientos del usuario deben simplemente en- 
focarse a los recursos principales que se deben proporcionar. Se ha redactado nuevamente el 
requerimiento para el editor de la cuadricula (Figura 6. 10) para enfocarlo solamente en las ca- 
racteristicas esenciales del sistema. 

Cuando sea posible, se debe intentar asociar un fundamento con cada requerimiento del 
usuario. El fundamento debe explicarpor que se ha incluido el requerimiento y es particu- 
larmente util cuando cambian estos. Por ejemplo, el fundamento en la Figura 6.10 reconoce 
que es de utilidad que una cuadricula activa situe automaticamente objetos en una linea de 
la cuadricula. Sin embargo, esto se rechaza de forma deliberada en favor de una ubicacion 
manual. Si en alguna etapa posterior se propone un cambio a esto, entonces estara claro que 
la utilizacion de una cuadricula pasiva fue algo premeditado mas que una decision de im- 
plementacion. 



recurso para el 
editor de cuadricula. 



2.6.1 Recursos de la cuadricula 

□ editor proporclonara un recurso para la cuadricula donde una matrizde lineas horizonta- 
ls y vertlcales proporciona un fondo para la ventana del editor. Esta cuadricula sera pasiva, 
donde la allneaclon de entidades es responsabllldad del usuario. 

Fundamento: Una cuadricula ayuda al usuario a crear un dlagrama ordenado con entida- 
des blen espacJadas. Aunque en una cuadricula activa pueda ser de utilidad que las enti- 
dades se ajusten a tas lineas de la cuadricula, la ublcaclon es Impreclsa. El usuario es la me- 
Jor persona para decldlr donde se deberfan u blear las entidades. 



Figura 6.10 Una 

definicion de un Especlflcacldn: ECUPSE/Vv5/Herramtentas/DE/FS Secclon 5.6 



Fuente; Ray Wilson, Glasgow Office 
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Para minimizar los malentendidos al redactar los requerimientos del usuario, se reco- 
mienda seguir algunas pautas sencillas: 

1. Inventar un formato estandar y asegurar que todos los requerimientos se adhieren al 
formato. Estandarizar el formato hace que las omisiones sean menos probables y los 
requerimientos mas faciles de verificar. El formato utilizado muestra el requerimien- 
to inicial en negrita, incluyendo una declaracion del fundamento con cada requeri- 
miento del usuario y una referencia a la especificacion mas detallada de los requeri- 
mientos del sistema. Tambien se puede incluir informacion sobre quien propuso el 
requerimiento (la fuente del requerimiento), de modo que se sepa a quien consultar si 
se tiene que cambiar el requerimiento. 

2. Utilizar el lenguaje de forma consistente. Siempre debe distinguir entre los requerimien- 
tos deseables y los obligatorios. Los requerimientos obligatorios son los requerimientos 
a los que el sistema debe dar soporte y normalmente se redactan en futuro simple. Los 
requerimientos deseables no son fundamentales y se redactan en futuro condicional. 

3. Resaltar el texto (con negrita, cursiva o color) para distinguir las partes clave del re- 
querimiento. 

4. Evitar, hasta donde seaposible, el uso dejerga informatica. Sin embargo, inevitable- 
mente se incluiran terminos tecnicos detallados en los requerimientos del usuario. 

Los Robertson (Roberton y Robertson, 1999), en su libro que estudia el metodo de inge- 
nieriade requerimientos VOL ERE, recomiendan que los requerimientos del usuario sean re- 
dactados inicialmente en tarjetas, un requerimiento por tarjeta. Sugieren varios campos en 
cada tarjeta, como el fundamento de los requerimientos, las dependencias con otros requeri- 
mientos, la fuente de los requerimientos, el material de apoyo, etcetera. Esto extiende el for- 
mato utilizado en la Figura 6.10, y se puede emplear tanto para requerimientos del usuario 
como del sistema. 

6.3 Requerimientos del sistema 

Los requerimientos del sistema son versiones extendidas de los requerimientos del usuario que 
son utilizados por los ingenieros de software como punto de partida para el diseno del siste- 
ma. Agregan detalle y explican como el sistema debe proporcionar los requerimientos del 
usuario. Pueden serutilizados como parte del contrato para la implementacion del sistema y, 
por lo tanto, deben seruna especificacion completay consistente del sistema entero. 

En teoria, los requerimientos del sistema simplemente deben describir el comportamiento 
externo del sistema y sus restricciones operativas. No deben tratarde como se debe disenaro 
implementar el sistema. Sin embargo, en el nivel de detalle requerido para especificar com- 
pletamente un sistema software complejo, es imposible, en la practica, excluir toda la infor- 
macion de diseno. Existen varias razones para esto: 

1 . Puede tener que disenar una arquitectura inicial del sistema para ayudar a estructurar 
la especificacion de requerimientos. Los requerimientos del sistema seorganizan con- 
forme a los diferentes subsistemas que componen el sistema. Como se expone en los 
Capitulos 7 y 18, esta definicion arquitectonica es esencial si quiere reutilizar compo- 
nentes software cuando implementa el sistema. 

2. En muchos casos, los sistemas deben interoperar con otros ya existentes. Esto restrin- 
ge el diseno, y estas restricciones imponen requerimientos en el sistema nuevo. 
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3. Es necesario el uso de una arquitectura especifica para satisfacer los requerimientos 
no funcionales (como la programacion por n versiones para conseguir fiabilidad, co- 
mentada en el Capitulo 20). Un regulador extemo que necesita certificar que el siste- 
ma es seguro puede especificar que undisefio arquitectonico que ya ha sido certifica- 
do sea utilizado. 

A menudo se utiliza el lenguaje natural para redactar, ademas de los requerimientos del 
usuario, las especificaciones de requerimientos del sistema. Sin embargo, debido a que los re- 
querimientos del sistema son mas detallados que los requerimientos del usuario, las especifi- 
caciones en lenguaje natural pueden ser confusas y dificiles de entender: 

1 . La comprension del lenguaje natural depende de que los lectores y redactores de la es- 
pecificacion utilicen las mismas palabras para el mismo concepto. Esto conduce a ma- 
las interpretaciones debido a la ambiguedad del lenguaje natural. Jackson (Jackson, 
1995) da un excelente ejemplo de esto cuando analiza las senales mostradas en una es- 
calera mecanica. Estas indican «Se deben utilizar zapatos» y «Los perros deben car- 
garse». Se dejan al lector las diferentes interpretaciones de estas frases. 

2. Una especificacion de requerimientos en lenguaje natural es demasiado flexible. Pue- 
de decir lo mismo de formas completamente diferentes. Se deja al lector decidir cuan- 
do los requerimientos son los mismos y cuando diferentes. 

3. No existe una forma facil de modularizar los requerimientos en lenguaje natural. Pue- 
de ser dificil encontrar todos los requerimientos relacionados. Para descubrir la con- 
secuencia de un cambio, puede ser necesario mirar todos los requerimientos en vez de 
solo un grupo de requerimientos relacionados. 

Debido a estos problemas, las especificaciones de requerimientos redactadas en lenguaje 
natural son propensas a malas interpretaciones. A menudo estas no se descubren hasta las fa- 
ses posteriores del proceso del software, y resolverlas puede resultar muy costoso. 

Es esencial redactar los requerimientos del usuario en un lenguaje que los no especialistas 
puedan entender. Sin embargo, se pueden redactar los requerimientos del sistema en unas no- 
taciones mas especializada (Figura 6.11). Estas incluyen un lenguaje natural estructurado y 



Lenguaje natural estructurado 



Lenguajes de descripcion de diseho 



Notaciones graficas 



Especificaciones matematicas 



Este enfoque depende de la definicion de formularios o plantillas estandares para 
expresar laespedncaaonde requerimientos. 

Este enfoque utiliza un lenguaje similar a uno de programacion, pero con caracte- 
risticas mas abstractas, para especificar los requerimientos por medio de la defini- 
cion de un modelo operativo del sistema. Este enfoque no se utiliza ampliamente 
en la actualidad, aunque puede ser util para especificaciones de interfaces. 

Para definir los requerimientos funcionales del sistema, se utiliza un lenguaje grafi- 
co, complementado con anotaciones de texto. Uno de los primeros lenguajes grafi- 
cos fue SADT (Ross, 1977) (Schoman y Ros, 1977). Actualmente, se suelen utilizar 
las descripciones de casos de uso (Jacobsen et al" 1993) y los diagramas de se- 
cuencia (Stevens y Pooley, 1999). 

Son notaciones que se basan en conceptos matematicos como el de las maquinas 
de estado finito o los conjuntos. Estas especificaciones no ambiguas reducen los ar- 
gumentos sobre la funcionalidad del sistema entre el clientey el contratista. Sin em- 
bargo, ta mayoria de los dientes no comprenden las especificaciones formales yson 
reacios a aceptarlas como un contrato del sistema. 



Figura 6.11 Notaciones para la especificacion de requerimientos. 
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estilizado, modelos graficos de los requerimientos como los casos de uso para las especifica- 
ciones matematicas formales. En este capitulo, se explica como el lenguaje natural estructu- 
rado complementado con modelos graficos sencillos puede utilizarse para redactar los reque- 
rimientos del sistema. Se estudia el modelado de sistemas graficos en el Capitulo 8 y la 
especificacion formal del sistema en el Capitulo 10. 



6.3.1 Especlflcaclones en lenguaje estmcturado 

El lenguaje natural estructurado es una forma de redactar los requerimientos del sistema 
donde la libertad del redactor de los requerimientos esta limitada y donde todos los re- 
querimientos se redactan de una forma estandar. La ventaja de este enfoque es que man- 
tiene la mayor parte de la expresividad y comprension del lenguaje natural, pero asegura 
que se imponga cierto grado de uniformidad en la especificacion. Las notaciones del len- 
guaje estructurado limitan la terminologia que se puede utilizar y emplean plantillas para 
especificar los requerimientos del sistema. Pueden incorporar construcciones de control 
derivadas de los lenguajes de programacion y manifestaciones graficas para dividir la es- 
pecificacion. 

Heninger (Heninger, 1980) describe uno de los primeros proyectos que utilizo el len- 
guaje natural estructurado para especificar los requerimientos del sistema. Se disefiaron for- 
mularios de proposito especial para describir la entrada, la salida y las funciones de un sis- 
tema software para un avion. Estos requerimientos se especificaron utilizando dichos 
formularios. 

Para utilizar un enfoque basado en formularios para especificar los requerimientos del sis- 
tema, se deben definir una o mas formularios o plantillas estandares para expresar estos re- 
querimientos. Se puede estructurar la especificacion alrededorde los objetos que manipula el 
sistema, las funciones ejecutadas por el sistema o los eventos procesados por este. En la Figu- 



Flgura 6.12 

La especificacion 
de requerimientos 
del sistema 
utilizando un 
formulario estandar. 
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Nhwl de azucar cfisminuyendo (r2 < rl) 


CompDose = 


0 


Nive) de azucar estable (r2 = rl) 


CompOose = 


0 


Nhret de azucar aumentando y tasa 

de incremento disminuyendo {(r2 - rl) < (rl - rt))) 


CompDose = 


0 



Figura 6.13 

Especificacion 
tabular del calculo. 



Nivel de azucar aumentando y tasa de incremento 
estable o aumentando. ((r2 - rl) > (rl - rO)) 



CompDose = redondear((r2 - rl)/4) 
Si resultado redondeado = 0 entonces 
CompDose = DosisMinima 
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ATM 



Base 

de datos 



Figura 6.14 
Diagrama 
de secuencia 
de la retirada de 
dinero en un ATM. 
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Gompletar 
transaction 



2. Tratar petition. El sistema trata la peticion del usuario. Para una retirada de dinero, se 
debe consultar la base de datos para comprobar el saldo del usuario y cargar la canti- 
dad retirada. Fijese aqui en la excepcion si el solicitante no tiene suficiente dinero en 
su cuenta. 

3. Completar transaction. Se devuelve la tarjeta del usuario y, cuando se ha extraido, se 
entrega el dinero y el recibo. 

Se veran de nuevo los diagramas de secuencia en el Capitulo 8, que trata los modelos de 
sistemas, y en el Capitulo 14, que estudia el disefio orientado a objetos. 



6.4 Especificacion de la interfaz 

Casi todos los sistemas software deben funcionar con otros sistemas que ya estan implemen- 
tados e instalados en el entorno. Si el sistema nuevo y los ya existentes deben trabajarjuntos, 
las interfaces de estos ultimos deben especificarse de forma precisa. Estas especificaciones se 
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deben definir al inicio del proceso y se incluyen (quizas como un apendice) en el documento 
de requerimientos. 

Existen tres tipos de interfaces que pueden definirse: 

1 . Interfaces de procedimientos en las cuales los programas o subsistemas existentes 
ofrecen una variedad de servicios a los que se accede invocando a los procedimientos 
de la interfaz. Estas interfaces a veces se denominan Interfaces de Programacion de 
Aplicaciones (APIs). 

2. Estructuras de datos que pasan de un subsistema a otro. Los modelos graficos de da- 
tos (descritos en el Capitulo 8) son las mejores notaciones para este tipo de descrip- 
cion. Si es necesario, se pueden generar automaticamente descripciones de programas 
en Java o C++ de estas descripciones. 

3. Representaciones de datos (como el orden de los bits) establecidas para un subsistema 
existente. Estas interfaces son muy comunes en sistemas de tiempo real embebido. A 1 - 
gunos lenguajes de programacion como Ada (aunque no Java) soportan este nivel de es- 
pecificacion. Sin embargo, la mejor forma de describir estos es probablemente utilizar un 
diagrama de la estructura con anotaciones que expliquen la funcion de cada grupo de bits. 

Las notaciones formales, analizadas en el Capitulo 10, permiten definir interfaces de una 
forma no ambigua, pero por su naturaleza no son comprensibles sin una formacion especial. 
Raramente se utilizan en lapracticapara la especificacion de interfaces, aunque son ideales a 
estos efectos. Se puede utilizar un lenguaje de programacion como Java para describir la sin- 
taxis de la interfaz. Sin embargo, esto se tiene que complementar con una descripcion adicio- 
nal que explique la semantica de cada una de las operaciones definidas. 

La Figura 6. 1 5 es un ejemplo de definicion de interfaz de procedimiento definida en Java. 
En este caso, esta es una interfaz de procedimiento ofrecidapor un servidor de impresion. Este 
gestiona una cola de espera de las peticiones de impresion de archivos en diferentes impre- 
soras. Los usuarios pueden examinar dicha cola de espera asociada con una impresora y pue- 
den eliminar sus trabajos de impresion de esa cola. Tambien pueden cambiar sus trabajos de 
una impresora a otra. La especificacion en la Figura 6.15 es un modelo abstracto del servidor 
de impresion que no muestra los detalles de la interfaz. La funcionalidad de las operaciones 
de esta se puede definir utilizando el lenguaje natural estructurado o la descripcion tabular. 

6.5 El documento de requerimientos del software 

El documento de requerimientos del software (algunas veces denominado especificacion de 
requerimientos del software o SRS) es la declaracion oficial de que deben implementar los 

Interface PrintServer { 

// define un servidor de impresion abstracto 
// requiere: interfaz Printer, interfaz PrintDoc 

// proporciona: initialize, print displayPrintOjueue, cancdPrirtllob, swftdiPrinter 
void initialize ( Printer p ) ; 
void print ( Printer p, PrintDoc d ) ; 
void dispJayPrmtQueue < Printer p ) ; 
void cancel Prinllob (printer p, PriDocd) ; 
void switchPrinter (Printer pi. Printer p2, PrintDoc d) ; 
}//PrintServer 



Figura 6.15 

La descripcion en 
PDL basado en Java 
de una interfaz 
del servidor 
de impresion. 
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desairolladores del sistema. Debe incluir tanto los requerimientos del usuario para el sistema 
como una especificacion detallada de los requerimientos del sistema. En algunos casos, los 
dos tipos de requerimientos se pueden integrar en una unica descripcion. En otros, los reque- 
rimientos del usuario se definen en una introduccion a la especificacion de los requerimien- 
tos del sistema. Si existe un gran numero de requerimientos, los detalles de los requerimien- 
tos del sistema se pueden presentaren un documento separado. 

El documento de requerimientos tiene un conjunto diverso de usuarios que va desde los al- 
tos cargos de la organizacion que pagan por el sistema, hasta los ingenieros responsables de 
desarrollar el software. La Figura 6.16, tomada de mi libro con Gerald Kotonya sobre inge- 
nieria de requerimientos (Kontonyay Sommerville, 1 998), ilustra los posibles usuarios del do- 
cumento y como lo utilizan. 

La diversidad de posibles usuarios significa que el documento de requerimientos tiene que 
presentar un equilibrio entre la comunicacion de los requerimientos a los clientes, la defini- 
cion de los requerimientos en el detalle exacto para los desairolladores y probadores, y la in- 
clusion de informacion sobre la posible evolucion del sistema. La informacion sobre cambios 
previstos puede ayudar a los disenadores del sistema a evitar decisiones de diseno restrictivas 
y a los ingenieros encargados del mantenimiento del sistema, quienes tienen que adaptar el 
sistema a los nuevos requerimientos. 

El nivel de detalle que se debe incluir en un documento de requerimientos depende del 
tipo de sistema que se desarrolle y del proceso de desarrollo utilizado. Cuando el sistema 
se desarrolle por un contratista externo, las especificaciones de los sistemas criticos nece- 
sitan ser claras y muy detalladas. Cuando haya mas flexibilidad en los requerimientos y 
cuando se utilice un proceso de desarrollo iterativo dentro de la empresa, el documento de 
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requerimientos puede ser mucho menos detallado y cualquier ambigiiedad resuelta duran- 
te el desarrollo del sistema. 

Varias organizaciones grandes, como el Departamento de Defensa de los Estados Unidos 
y el IEEE, han definido estandares para los documentos de requerimientos. Davis (Davis, 
1993) analiza algunos de estos estandares y compara sus contenidos. El estandar mas am- 
pliamenteconocidoes el IEEE/ANSI 830-1998 (IEEE, 1998). Este estandar IEEE sugiere la 
siguiente estructura para los documentos de requerimientos: 

1. I n trod u cci on 

1.1 Proposito del documento de requerimientos 

1.2 Alcance del producto 

1.3 Definiciones, acronicos y abreviaturas 

1.4 Referencias 

1.5 Descripcion del resto del documento 

2. Desc ri pci on general 

2.1 Perspectiva del producto 

2.2 Funciones del producto 

2.3 Caracteristicasdelusuario 

2.4 Restricciones generales 

2.5 Suposiciones y dependencias 

3. Requerimientos especfficos: incluyen los requerimientos funcionales, no funciona- 
les y de interfaz. Obviamente, esta es la parte mas sustancial del documento, pero de- 
bido a la ampliavariabilidadenlapracticaorganizacional,no esapropiadodefiniruna 
estructura estandar para esta seccion. Los requerimientos pueden documentar las in- 
terfaces externas, describir la funcionalidad y el rendimiento del sistema, especificar 
los requerimientos logicos de la base de datos, las restricciones de diseflo, las propie- 
dades emergentes del sistema y las caracteristicas de calidad. 

4. Apendices 

5. Indice 

Aunque el estandar IEEE no es ideal, contiene muchos consejos sobre como redactar los 
requerimientos y como evitar problemas. Es muy general para que pueda ser un estandar de 
una organizacion. Es un marco general que se puede transformar y adaptar para definir un es- 
tandar ajustado a las necesidades de una organizacion en particular. La Figura 6.17 ilustrauna 
posible organizacion paraun documento de requerimientos que se basa en el estandar IEEE. 
Sin embargo, se ha ampliado para incluir informacion sobre la evolucion predicha del siste- 
ma. Esto fue propuesto por primera vez por Heninger (Heninger, 1980) y, como se ha indica- 
do, ayuda a las personas encargadas del mantenimiento del sistema y puede permitir a los di- 
senadores incluir soporte para futuras caracteristicas del sistema. 

Por supuesto, la informacion que se incluya en un documento de requerimientos debe de- 
pcndcr del tipo dc software a dcsarrollary del enfoque dc desarrollo que sc utilice. Si sc adop- 
ta un enfoque evolutivo para un producto de software (por ejemplo), el documento de reque- 
rimientos dejara fuera muchos de los capitulos detallados sugeridos anteriormente. El interes 
estara en definir los requerimientos del usuario y los requerimientos del sistema no funcio- 
nales de alto nivel. En este caso, los disenadores y programadores utilizan su juicio para de- 
cidircomo satisfacerel esquema de los requerimientos del usuario para el sistema. 

Por el contrario, cuando el software es pane de un proyecto de ingenieria de sistemas gran- 
de que incluye la interaccion de sistemas hardware y software, a menudo es fundamental de- 
finir con mucho detalle los requerimientos. Esto significa que el documento de requerimien- 
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tos probablemente sea muy extenso y deba incluir la mayoria si no la totalidad de los capitu- 
los que se muestran en la Figura 6.17. Para documentos extensos, es de particular importan- 
cia incluir una tabla de contenido comprensible y un indice del documento para que asi los 
lectores puedan encontrar la informacion que necesitan. 

El documento de requerimientos es fundamental cuando un contratista exterior esta desarro- 
llando el sistema software. Sin embargo, los metodos de desarrollo agiles sostienen que los reque- 
rimientos cambian tan rapidamente que un documento de requerimientos se queda desfasado en 
cuanto se redacta, por lo que el esfuerzo en gran parte se malgasta. Mas que un documento formal, 
enfoques como laprogramacion extrema (Beck, 1999) proponen que los requerimientos del usua- 
rio deberian ser recogidos incrementalmente y escritos en tarjetas. El usuario entonces da priori- 
dad a los requerimientos que se han de implementar en el siguiente incremento del sistema. 

Para sistemas de negocio donde los requerimientos son inestables, pienso que este enfo- 
que esbueno. Sin embargo, argumentariaque todavia esutil redactar un breve documento de 
soporte que defina el negocio y los requerimientos de confiabilidad del sistema. Es facil ol- 
vidarse de los requerimientos que se aplican al sistema en su totalidad al centrarse en los re- 
querimientos funcionales para la siguiente entrega del sistema. 





Prefacio 


Debe definir los posibles lectores del documento y describir su version de la historia, in- 
duyendo un fundamento para la creation de una nueva version y un resumen de los 
carnbios hechos en cada una. 


Introduction 


Debe desaibir la necesidad del sistema. Oebe describir brevemente sus funtiones y ex- 
plkar como trabajari con otros sistemas. Oebe describir la manera en que este se ad- 
Were af negocio total u objebVos estrstegkos de ta organization que solitita el software. 


Glosario 


Debe definir los terminos tecnicos utflizados en d documento No se deben hacer su> 
prjskiones de la experience o peritia del lector. 


Definition de requerimientos 
del usuario 


En esta section se deben describir los servitios que se proporbonan ai usuaho y los re- 
querimientos no funcionates del sistema. Esta description puede ublizw lenguaje natu- 
ral, diagramas u otras notationes que sea comprensibles para los dientes. Se deben es- 
pecrficar los estindares de produdDs y procesos a seguir. 


Arqurtectura del sistema 


Este capftulo debe presenter una vision general de alto nivel de la aiquitectura prevista 
del sistema que muestre la distribution de funtiones en los mOdulos del sistema. Se de- 
ben resaltar los components arquitectonicos reutifizados. 


Espedfication de requerimientos 
del sistema 


Debe describir con mayor detalle los requerimientos funcionales y no funcionales. Si es 
necesario, se pueden enfatizar los no funcionales; por ejemplo, se pueden definir las in- 
terfaces con otros sistemas. 


Modelos del sistema 


Se deben exporter uno o mas modelos del sistema que muestren las relationes entre 
los compooerrtes del sistema y el sistema y su entomo. Estos podrfan ser modelos de 
objetes, modelos de flujos de dates y modelos de dates semanticos. 


Evolution del sistema 


Debe describir las supostdones fundamentales sobre las cuales se basa el sistema y los 
carnbios previstos debido a la evolution del hardware, carnbios en las necesidades del 
usuario* etcetera. 


Apendices 


Debe proporcionar rrrformaciOn detaBeda y pretisa relationada con la apBcadOn quese 
desanoHa. Algunos ejemplos de apendices que pueden induirse son las descripdones 
del hardware y de la base de dates, los requerimientos de hardware definen las contV 
gurationes mmfcna y optima del sistema. Los de la base de dates definen la organiza- 
tion logics de los dates utilizados por d sistema y las relationes entre los dates. 



Indice Se pueden induir varios Indices en el documento. Ademas de un indice alfabetico, pue- 

de haber un indice de diagramas, un indice de funtiones, etcetera. 



Figura 6.17 La estructura de un documento de requerimientos. 
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PUNTOS CLAVE 

• Los requerimientos para un sistema software determinan lo que debe hacer el sistema y definen tas restric- 
cionesensufuncionamientoejmplementacion. 

• Los requerimientos funcionales son declaraciones de los servicios que el sistema debe proporcionar o son des- 
cripciones de como se deben llevar a cabo algunos calculos. Los requerimientos del dominio son requeri- 
mientos funcionales que se derivan de las caractensticas del dominio de a plicacion. 

• Los requerimientos no funcionales restringen el sistema en desarrollo y el proceso de desarrollo que se debe 
utilizar. Pueden ser requerimientos del producto, organizacionales o externos. A menudo estan relacionados 
con tas propiedades emergentes del sistema y, por to tanto, se aplican al sistema completo. 

• Los requerimientos del usuarioson para el uso por la gente relacionada con la utilizacionyobtencion del sis- 
tema. Se deben redactar en lenguaje natural, con tablas y diagramas que sean faciles de entender. 

• Los requerimientos del sistema se utilizan para comunicar, de forma precisa, las funciones que debe propor- 
cionar el sistema. Para reducir la ambigiiedad, se pueden redactar en un formulario estructurado del lengua- 
je natural complementado con tablas y modelos del sistema. 

• Los documentos de requerimientos de software son la declaracion acordada de los requerimientos del siste- 
ma. Se deben organizar de tal forma que puedan ser utilizados tanto por los clientes del sistema como por los 
desarro dadores del software. 

• El estandar IEEE para los documentos de requerimientos es un punto de partida util para estandares mas es- 
pecificos de especif icacidn de requerimientos. 



LECTURAS ADICIONALES Mb. Ill Kwill Will 111111111111111 11 111 till II I y 111 

Software Requirements, 2nd ed. Este libro, disenado por los escritores y usuarios de los requerimientos, describe 
las buenaspracticasde la ingenieria de requerimientos. (K. M. Weigers, 2003, Microsoft Press.) 

Mastering the Requirements Process. Un libro bien escribo y facil de leer que e s ta basado en un metodo en concre- 
to (VOLERE), pero el cual tambien incluye muchos buenos consejos generates sobre la ingenieria de requerimien- 
tos. (S. Robertson y J. Robertson, 1999, Addison-Wesley.) 

Requirements Engineering: Processes and Techniques. Este libro abarca todos los aspectos del proceso de inge- 
nieria de requerimientos y trata tecnicas concretas de la especificacion de requerimientos. (G. Kotonya e I. Som- 
merville, 1998, John Wiley & Sons.) 

Software Requirements Engineering. Esta coleccion de articulos sobre ingenieria de requerimientos incluye varios 
articulos relevantes como «Recommended Practice for Software Requirements Specification)), un estudio del es- 
tandar IEEE para los documentos de requerimientos. [R. H. Thayer y M. Dorfman (eds.), 1997, IEEE Computer Society 
Press.] 
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EJERCICIOS 



6l1 Identifique y comente brevemente cuatro tipos de requerimientos que se pueden definir para un sistema In- 
formatlco. 

62 Comente los problemas de la utilizacidn del lenguaje natural para definir los requerimientos del usuario y 
del sistema, y muestre, utilizando pequenos ejemplos, como el estructurar el lenguaje natural en formula- 
rios puede ayudar a evitar algunas de estas dificultades. 

63 Descubra lasambigiiedadesu omisiones en la siguiente declaracion de requerimientos de una parte de un 
sistema expendedor de billetes. 

Un sistema automatico de expedicion de billetes vende billetes de tren. Los usuarios seleccionan su desti- 
no e introduce n una tarjeta decreditoyunnumerode identification personal. El billete de tren se expide y 
se carga su cuenta de la tarjeta de credito. Cuando el usuario presiona el boton de inicio, se activa un menu 
que muestra (os postbles destinos, junto con un mensaje para el usuario que le indica que seleccione el des- 
tino. Una vez que se ha seleccionado un destino, se pide a los usuarios que introduzcan su tarjeta de credi- 
to. Se comprueba su validez y entonces se le pide introducir un identificador personal. Cuando la transac- 
cion de credito se haya validado, se expide el billete. 

6A Vuelva a redactar la description anterior utilizando el enfoque estructurado descrito en este capitulo. Re- 
suelva de forma apropiada lasambigiiedades identificadas. 

6.5 Dibuje un diagrama de secuencias que muestre las acciones llevadas a cabo en el sistema expendedor de 
billetes. Puede hacer algunas suposiciones razonables sobre el sistema. Ponga especial atencion en la es- 
pecificacion de los errores del usuario. 

6.6 Utilizando la tecnica sugerida aqui, en la que el lenguaje natural se presenta en una forma estandar, redac- 
te requerimientos del usuario verosimiles para las siguientes funciones: 

• La funcion de expedicion de dinero en un cajero automatico de un banco. 

• La verif icacion de ortografia y la funcion de correccion en un procesador de texto. 

• Un sistema de autoservicio de bombas de gasolina que incluye un lector de tarjetas de credito. El clien- 
te pasa la tarjeta a traves del lectory especifica la cantidad de combustible requerido. Este se entrega y 
se hace el cargo a la cuenta del cliente. 

6.7 Describa cuatro tipos de requerimientos no funcionales que pueden existir en un sistema. De ejemplos de 
cada uno de estos tipos de requerimientos. 

6-8 Redacte un conjunto de requerimientos no funcionales para el sistema expendedor de billetes, especifi- 
cando su habilidad y su respuesta en el tiempo. 

6.9 Sugiera la manera en que un ingeniero responsable de preparar la especif icacion de requerimientos del sis- 
tema podria controlar las relaciones entre los requerimientos funcionales y no funcionales. 

6.10 Ha obtenido un trabajo con un usuario de software quien ha contratado a su anterior compahia para des- 
a i ro liar un sistema. Usted descubre que la interpretacion de su compahia actual de los requerimientos es 
diferente de la tomada por su anterior compahia. Comente que nana en tal situacion. Usted sabe que los 
costes desu compahia actual seincrementaransilasambigiiedadesnose resuelven. Tambientieneuna res- 
ponsabilidad de confidencialidad para su anterior compahia. 



Procesos de la ingeniena 
requerimientos 



Objetivos 

El objetivo de este capitulo es tratar las actividades implicadas en 
el proceso de ingeniena de requerimientos. Cuando haya leido 
este capitulo: 

• comprendera las principales actividades de la ingenieria de 
requerimientos y sus relaciones; 

• habra sido introducido en diversas tecnicas para la obtencion 
y analisis de requerimientos; 

• comprendera la importancia de la validacion de 
requerimientos y como se utilizan las revisiones de estos en 
este proceso; 

• comprendera por que es necesaria la gestion de 
requerimientos y como ayuda a otras actividades de la 
ingenieria de requerimientos. 

Contenidos 

7.1 Estudios de viabilidad 

7.2 Obtencion y analisis de requerimientos 

7.3 Validacion de requerimientos 

7.4 Gestion de requerimientos 
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CAPITULO 7 



Procesos de la ingenieria de requerimientos 



La meta del proceso de ingenieria de requerimientos es creary mantener un documento de re- 
querimientos del sistema. El proceso general corresponde cuatro subprocesos de alto nivel de 
la ingenieria de requerimientos. Estos tratan de la evaluacion de si el sistema es util para el 
negocio (estudio de viabilidad); el descubrimiento de requerimientos (obtencion y analisis); 
la transformacion de estos requerimientos en formularios estandar (especificacion), y la veri- 
ficacion de que los requerimientos realmente definen el sistema que quiere el cliente (valida- 
cion). La Figura 7.1 ilustra la relacion entre estas actividades. Tambien muestra el documen- 
to que se elabora en cada etapa del proceso de ingenieria de requerimientos. La especificacion 
y la documentacion se estudian en el Capitulo 6; este capitulo se centra en las actividades de 
la ingenieria de requerimientos. 

Las actividades que se muestran en la Figura 7.1 se refieren al descubrimiento, documen- 
tacion y verificacion de requerimientos. Sin embargo, en casi todos los sistemas los requeri- 
mientos cambian. Las personas involucradas desarrollan una mejor comprension de lo que 
quieren que haga el software; la organizacion que compra el sistema cambia; se hacen modi- 
ficaciones a los sistemas hardware, software y al enlomo organizacional. El proceso de ges- 
tionar estos cambios en los requerimientos se denomina gestion de requerimientos, tema que 
se aborda en la seccion final de este capitulo. 

Se presenta una perspectiva alternativa sobre el proceso de ingenieria de requerimientos en 
la Figura 7.2. Esta muestra el proceso como una actividad de tres etapas donde las activida- 
des se organizan como un proceso iterativo alrededor de una espiral. La cantidad de dinero y 
esfuerzo dedicados a cada actividad en una iteracion depende de la etapa del proceso general 
y del tipo de sistema desarrollado. Al principio del proceso, se dedicara la mayorparte del es- 
fuerzo a la comprension del negocio de alto nivel y los requerimientos no funcionales y del 
usuario. Al final del proceso, en el anillo exterior de la espiral, se dedicara un mayor esfuer- 
zo a la ingenieria de requerimientos del sistema y al modelado de este. 

Este modelo en espiral satisface enfoques de desarrollo en los cuales los requerimientos se 
desarrollan a diferentes niveles de detalle. El numero de iteraciones alrededor de la espiral 
puede variar, por lo que se puede salirde la espiral despues de que se hayan obtenido algunos 
o todos los requerimientos del usuario. Si la actividad de construccion de prototipos mostra- 
da debajo de la validacion de requerimientos se extiende para incluir el desarrollo iterativo, 
como se indica en el Capitulo 17, este modelo permite que los requerimientos y la imple- 
mentacion del sistema se desarrollen al mismo tiempo. 



Figura 7.1 
El proceso 

de ingenieria 

de requerimientos. 




*" Documento de 
requerimientos 
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Algunas personas consideran a la ingenieria de requerimientos como el proceso de aplicar 
un metodo de analisis estructurado, como el analisis orientado a objetos (Larman, 2002). Este 
comprende analizar el sistema y desarrollar un conjunto de modelos graficos del mismo, 
como los modelos de casos de uso. que sirven como una especificacion del sistema. El con- 
junto de modelos describe el comportamiento del sistema al cual se le agregan notas con in- 
formacion adicional que detallan, por ejemplo, el rendimiento o fiabilidad requeridos. 

Aunque los metodos estructurados juegan un cierto papel en el proceso de ingenieria de 
requerimientos, existe mucho mas en dicha ingenieria de lo que se abarca en estos metodos. 
La obtencion de requerimientos, en particular, es una actividad centrada en las personas, y a 
estas no les gustan las restricciones impuestas por modelos de sistemas rigidos. Aqui se tra- 
tan los enfoques generales de la ingenieria de requerimientos, y en el Capitulo 8 se examinan 
los metodos estructurados y los modelos del sistema. 



7.1 Estudios de viabilidad 

Para todos los sistemas nuevos, el proceso de ingenieria de requerimientos deberia empezar 
con un estudio de viabilidad. La entrada de este es un conjunto de requerimientos de negocio 
preliminares, una descripcion resumida del sistema y de como este pretende contribuir a los 
procesos del negocio. Los resultados del estudio de viabilidad deberian serun informe quere- 
comiende si merece o no la pena seguir con la ingenieria de requerimientos y el proceso de 
desarrollo del sistema. 
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Un estudio de viabilidad es un estudio corto y orientado a resolver varias cuestiones: 

1 . ^Contribuye el sistema a los objetivos generales de la organizacion? 

2. ^Se puede implementar el sistema utilizando la tecnologia actual y dentro de las res- 
tricciones de coste y tiempo? 

3. ^Puede integrarse el sistema con otros sistemas existentes en la organizacion? 

La cuestion de si el sistema contribuye a los objetivos del negocio es critica. Si no contri- 
buye a estos objetivos, entonces no tiene un valor real en el negocio. Aunque esto pueda pa- 
recer obvio, muchas organizaciones desarrollan sistemas que no contribuyen a sus objetivos 
porque no tienen una clara declaracion de estos objetivos, porque no consiguen definir los re- 
querimientos del negocio para el sistema o porque otros factores politicos u organizacionales 
influyen en lacreacion del sistema. Aunque no se trataexpHcitamente, un estudio de viabili- 
dad deberia ser parte de la fase de Inicio del Proceso Unificado de Rational, como se comen- 
to en el Capitulo 4. 

Llevar a cabo un estudio de viabilidad comprende la evaluacion y recopilacion de la in- 
formacion, y la redaccion de informes. La fase de evaluacion de la informacion identifica la 
informacion requerida para contestar las tres preguntas anteriores. Una vez que dicha infor- 
macion se ha identificado, se deberia hablar con las fuentes de informacionpara descubrir las 
respuestas a estas preguntas. Algunos ejemplos de preguntas posibles son: 

1. i,C6mo se las arreglaria la organizacion si no se implementara este sistema? 

2. ^Cuales son los problemas con los procesos actuales y como ayudaria un sistema nue- 
vo a aliviarlos? 

3. ^Cual es la contribucion directa que hara el sistema a los objetivos y requerimientos 
del negocio? 

4. ^La informacion se puede obtener y transferir a otros sistemas de la organizacion? 

5. ^Requiere el sistema tecnologia que no se ha utilizado previamente en la organiza- 
cion? 

6. ^A que debe ayudar el sistema y a que no necesita ayudar? 

En un estudio de viabilidad, se pueden consultar las fuentes de informacion, como los je- 
fes de los departamentos donde se utilizara el sistema, los ingenieros de software que estan 
familiarizados con el tipo de sistema propuesto, los expertos en tecnologia y los usuarios fi- 
nales del sistema. Normalmente, se deberia intentar completarun estudio de viabilidad endos 
o tres semanas. 

Una vez que se tiene la informacion, se redacta el informe del estudio de viabilidad. De- 
beria hacerse una recomendacion sobre si debe continuar o no el desarrollo del sistema. En el 
informe, se pueden proponer cambios en el alcance, el presupuesto y la confeccion de agen- 
das del sistema y sugerir requerimientos adicionales de alto nivel para este. 

7.2 Obtencion y analisis de requerimientos 

La siguiente etapa del proceso de ingenieria de requerimientos es la obtencion y analisis de 
requerimientos. En esta actividad, los ingenieros de software trabajan con los clientes y los 
usuarios finales del sistema para determinar el dominio de la aplicacion, que servicios debe 
proporcionar el sistema, el rendimiento requerido del sistema, las restricciones hardware, et- 
cetera. 
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La obtencion y analisis de requerimientos pueden afectar a varias personas de la orga- 
nizacion. El termino stakeholder se utiliza para referirse a cualquier persona o grupo que 
se vera afectado por el sistema, directa o indirectamente. Entre los stakeholders se encuen- 
tran los usuarios finales que interactuan con el sistema y todos aquellos en la organizacion 
que se pueden ver afectados por su instalacion. Otros stakeholders del sistema pueden ser 
los ingenieros que desarrollan o dan mantenimiento a otros sistemas relacionados, los ge- 
rentes del negocio, los expertos en el dominio del sistema y los representantes de los tra- 
bajadores. 

Obtener y comprender los requerimientos de los stakeholders es dificil por varias razones: 

1. Los stakeholders a menudo no conocen lo que desean obtener del sistema informati- 
co excepto en terminos muy generales; puede resultarles dificil expresar lo que quie- 
ren que haga el sistema o pueden hacer demandas irreales debido a que no conocen el 
coste de sus peticiones. 

2. Los stakeholders expresan los requerimientos con sus propios terminos de forma na- 
tural y con un conocimiento implicito de su propio trabajo. Los ingenieros de reque- 
rimientos, sin experiencia en el dominio del cliente, deben comprender estos requeri- 
mientos. 

3. Diferentes stakeholders tienen requerimientos distintos, que pueden expresar de varias 
formas. Los ingenieros de requerimientos tienen que considerar todas las fuentes po- 
tenciales de requerimientos y descubrir las concordancias y los conflictos. 

4. Los factores politicos pueden influir en los requerimientos del sistema. Por ejemplo, 
los directivos pueden solicitar requerimientos especificos del sistema que incremen- 
taran su infiuencia en la organizacion. 

5. El entorno economico y de negocios en el que se lleva a cabo el analisis es dinamico. 
Inevitablemente, cambia durante el proceso de analisis. Por lo tanto, la importancia de 
ciertos requerimientos puede cambiar. Pueden emerger nuevos requerimientos de nue- 
vos stakeholders que no habian sido consultados previamente. 

En la Figura 7.3 se muestra un modelo muy general del proceso de obtencion y analisis. 
Cada organizacion tendra su propia version o instancia de este modelo general, dependiendo 
de los factores locales como la habilidad del personal, el tipo de sistema a desarrollary los 
estandares utilizados. De nuevo, se puede pensar en estas actividades dentro de una espiral de 
forma que las actividades se entrelazan a medida que el proceso avanza desde el anillo inte- 
rior a los exteriores de la espiral. 

Las actividades del proceso son: 

1 . Descubrimiento de requerimientos. Es el proceso de interactuar con los stakeholders 
del sistema para recopilar sus requerimientos. Los requerimientos del dominio de los 
stakeholders y ladocumentacion tambien se descubren durante esta actividad. 

2. Clasiflcacion y organizacion de requerimientos. Esta actividad toma la recopilacion 
no estructurada de requerimientos, grupos relacionados de requerimientos y los orga- 
niza en grupos coherentes. 

3. Ordenacidn por prioridades y negociacidn de requerimientos. Inevitablemente, cuan- 
do existen muchos stakeholders involucrados, los requerimientos entraran en conflic- 
to. Esta actividad se refiere a ordenar segun las prioridades los requerimientos, y a en- 
contrary resolver los requerimientos en conflicto a traves de lanegociacion. 

4. Documentation de requerimientos. Se documentan los requerimientos y se entra en la 
siguiente vuelta de la espiral. Se pueden producir documentos de requerimientos for- 
males o informales. 
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Figura 7.3 
El proceso 
de obtencion 
y analisis de 
requerimientos. 




La Figura 7.3 muestra que la obtencion y analisis de requerimientos es un proceso iterati- 
vo con retroalimentacion continua de cada actividad a las otras actividades. El ciclo del pro- 
ceso comienza con el descubrimiento de requerimientos y termina con la documentacion de 
requerimientos. La comprension de los requerimientos por parte del analista mejora con cada 
vuelta del ciclo. 

En este capitulo, se trata principalmente el descubrimiento de requerimientos y en varias 
tecnicas que se han desarrollado para darle soporte. La clasificacion y organizacion de reque- 
rimientos principalmente se refiere a la identificacion de requerimientos coincidentes de dife- 
rentes stakeholders y a la agrupacion de requerimientos relacionados. La forma mas comun 
de agrupar requerimientos es utilizar un modelo de la arquitectura del sistema para identificar 
los subsistemas y asociar los requerimientos con cada subsistema. Eslo pone de manifiesto que 
la ingenieria de requerimientos y el diseno arquitectonico no siempre se pueden separar. 

Inevitablemente, los stakeholders tienen opiniones diferentes sobre la importancia y prio- 
ridad de los requerimientos, y algunas veces estas opiniones estan renidas. Durante el proce- 
so, se deberian organizar frecuentes negociaciones con los stakeholders para que se pueda lie- 
gar a acuerdos. Es imposible satisfacer completamente a todos los stakeholders, pero si algun 
stakeholder piensa que sus opiniones no se han considerado adecuadamente, deliberadamen- 
te puede intentar socavar el proceso de ingenieria de requerimientos. 
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En la etapa de la documentacion de requerimientos, los requerimientos que se han obteni- 
do se documentan de tal forma que se pueden utilizar para ayudar al descubrimiento de nue- 
vos requerimientos. En esta etapa, se puede producir una version inicial del documento de re- 
querimientos del sistema, pero faltaran secciones y habra requerimientos incompletos. Por 
otra parte, los requerimientos se pueden documentar como tablas en un documento o en tar- 
jetas. Redactar requerimientos en tarjetas (el enfoque utilizado en la programacion extrema) 
puede ser muy efectivo, ya que son faciles de manejar, cambiar y organizar para los stake- 
holders. 

7.2.1 Descubrimiento de requerimientos 

El descubrimiento de requerimientos es el proceso de recoger informacion sobre el sistema 
propuesto y los existentes y extraer los requerimientos del usuario y del sistema de esta in- 
formacion. Las fuentes de informacion durante la fase del descubrimiento de requerimien- 
tos incluyen la documentacion, los stakeholders del sistema y la especificacion de sistemas 
similares. Usted se relaciona con los stakeholders a traves de entrevistas y de la observacion, 
y puede utilizar escenarios y prototipos para ayudar al descubrimiento de requerimientos. En 
esta seccion, se analiza un enfoque que ayuda a asegurar a que consiga una amplia cobertu- 
ra de stakeholders al descubrir requerimientos, y se describen tecnicas de descubrimiento de 
requerimientos entre las que se incluyen entrevistas, escenarios y etnografia. Otras tecnicas 
de descubrimiento de requerimientos que se pueden utilizar son los metodos de analisis es- 
tructurado, estudiados en el Capitulo 8, y la construccion de prototipos del sistema, que se 
trata en el Capitulo 17. 

Son stakeholders desde los usuarios finales del sistema hasta los gerentes y stakeholders 
extemos como los reguladores quienes certifican la aceptabilidad del sistema. Por ejemplo, 
entre los stakeholders del sistema para un cajero automatico (ATM) de un banco se encuen- 
tran: 

1. Los clientes actuales del banco quienes reciben los servicios del sistema 

2. Los representantes de otros bancos quienes tienen acuerdos reciprocos que les permi- 
ten utilizar otros ATMs 

3. Los directores de las sucursales bancarias quienes obtienen informacion del sistema 

4. El personal de ventanilla de las sucursales bancarias quienes estan relacionados con 
el funcionamiento diario del sistema 

5. Los administradores de la base de datos quienes son responsables de integrar el siste- 
ma con la base de datos de clientes del banco 

6. Los administradores de seguridad del banco quienes deben asegurar que el sistema no 
suponga un riesgo de seguridad 

7. Las personas del departamento de marketing del banco quienes probablemente estan 
interesadas en utilizar el sistema como un medio para promocionar al banco 

8. Los ingenieros de mantenimiento de hardware y software quienes son responsables de 
mantener y actualizar el hardware y el software 

9. Los reguladores de la banca nacional quienes son responsables de asegurar que el sis- 
tema se ajusta a las regulaciones de la banca 

Ademas de los stakeholders del sistema, ya hemos visto que los requerimientos pueden ve- 
nir del dominio de la aplicacion y de otros sistemas que interactuan con el sistema a especi- 
ficar. Todos estos se deben considerar durante el proceso de obtencion de requerimientos. 
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Estas fuentes de requerimientos (stakeholders, dominio, sistemas) se pueden representar 
como puntos de vista del sistema, donde cada uno presenta un subconjunto de requerimien- 
tos para el sistema. Cada punto de vista proporciona una perspectiva nueva en el sistema, pero 
estas no son completamente independientes. Por lo general coinciden parcialmente, por lo que 
tienen requerimientos comunes. 

Punios de vista 

Los enfoques orientados a puntos de vista para la ingenieria de requerimientos (Mullery, 
1979; Finkelstein et al, 1992; Kotonya y Sommerville, 1992; Kotonya y Sommerville, 1996) 
organizan tanto el proceso de obtencion como los requerimientos mismos utilizando puntos 
de vista. Un punto clave del analisis orientado a puntos de vista es que reconoce varias pers- 
pectivas y proporciona un marco de trabajo para descubrir conflictos en los requerimientos 
propuestos por diferentes stakeholders. 

Los puntos de vista se pueden utilizar como una forma de clasificar los stakeholders y otras 
fuentes de requerimientos. Existen tres tipos genericos de puntos de vista: 

1 . Puntos de vista de los interactuadores: representan a las personas u otros sistemas que 
interactuan directamente con el sistema. En el sistema del A T M del banco, son ejem- 
plos de estos puntos de vista los clientes del banco y la base de datos de las cuentas 
bancarias. 

2 . Puntos de vista indirectos: representan a los stakeholders que no utilizan el sistema 
ellos mismos pero que influyen en los requerimientos de algun modo. En el sistema 
del ATM del banco, son ejemplos de puntos de vista indirectos la gerencia del banco 
y el personal de seguridad. 

3. Puntos de vista del dominio: representan las caracteristicas y restricciones del domi- 
nio que influyen en los requerimientos del sistema. En el sistema del ATM del banco, 
un ejemplo de un punto de vista del dominio serian los estandares que se han des- 
arrollado para las comunicaciones interbancarias. 

Por lo general, estos puntos de vista proporcionan diferentes tipos de requerimientos. Los 
puntos de vista de los interactuadores proporcionan requerimientos detallados del sistema 
que cubren las caracteristicas e interfaces del mismo. Los puntos de vista indirectos es mas 
probable que proporcionen requerimientos y restricciones organizacionales de alto nivel. 
Los puntos de vista del dominio proporcionan restricciones del dominio que se aplican al 
sistema. 

La identificacion inicial de los puntos de vista que son relevantes a un sistema a veces pue- 
de ser dificil. Para ayudar a este proceso, se deberia intentar identificar tipos de puntos de vis- 
ta mas especificos: 

1. Los proveedores de servicios al sistema y los receptores de los servicios del sistema. 

2. Los sistemas que deben interactuar directamente con el sistema a especificar. 

3. Las regulaciones y estandares que se aplican al sistema. 

4. Las fuentes de los requerimientos no funcionales y de negocio del sistema. 

5. Los puntos de vista de la ingenieria que reflejan los requerimientos de las personas que 
tienen que desarrollar, administrar y mantener el sistema. 

6. Los puntos de vista del marketing y otros que generan requerimientos sobre las ca- 
racteristicas del producto esperadas por los clientes y como el sistema deberia reflejar 
la imagen externa de la organizacion. 
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Figura 7.4 Puntos de vista en el LIBSYS. 



2. Entrevistas abiertas donde no hay un programa predefinido. El equipo de la ingenie- 
ria de requerimientos examina una seria de cuestiones con los stakeholders del siste- 
ma y, por lo tanto, desarrolla una mejor comprension de sus necesidades. 

En lapractica, las entrevistas con los stakeholders normalmente son una mezcla de estos. 
Las respuestas a algunas preguntas pueden conducir a otras cuestiones que se discuten de una 
forma menos estructurada. Las discusiones completamente abiertas raramente salen bien; la 
mayoria de las entrevistas requieren algunas preguntas para empezar y para mantener la en- 
trevista centrada en el sistema a desarrollar. 

Las entrevistas sirven para obteneruna comprension general de lo que hacen los stakehol- 
ders, como podrian interactuar con el sistema y las dificultades a las que se enfrentan con los 
sistemas actuales. A la gente le gusta hablar sobre su trabajo y normalmente se alegran de ver- 
se implicados en las entrevistas. Sin embargo, no son de tanta utilidad para la comprension 
de los requerimientos del dominio de la aplicacion. 

Es dificil obtener conocimiento del dominio durante las entrevistas debido a dos razones: 

1. Todos los especialistas de la aplicacion utilizan terminologia y jerga especifica de un 
dominio. Es imposibleparaellos discutir requerimientos del dominio sinutilizar esta 
terminologia. Normalmente la utilizan de un modo preciso y sutil, por lo que es facil 
que la malinterpreten los ingenieros de requerimientos. 

2. Cierto conocimiento del dominio es tan familiar para los stakeholders que o lo en- 
cuentran dificil de explicar o piensan que es tan basico que no merece la pena men- 
cionarlo. Porejemplo, paraun bibliotecario, es evidente que todas las adquisicio- 
nes se catalogan antes de agregarlas a la biblioteca. Sin embargo, esto puede no 
ser obvio para el entrevistados por lo que no se tiene en cuenta en los requeri- 
mientos. 

Las entrevistas no son una tecnica eficaz para obtener conocimiento sobre los requeri- 
mientos y restricciones organizacionales debido a que existen sutiles poderes e influencias en- 



7.2 • Obtencion y analisis de requerimientos 



139 



tre los stakeholders en la organizacion. Las estructuras organizacionales publicadas rara vez 
se corresponden con la realidad de la loma de decisiones en una organizacion, pero los entre- 
vistados pueden no desear revelar la estructura real en vez de la teorica a un desconocido. En 
general, la mayoriade lagente es reacia a discutir cuestiones politicasy organizacionales que 
pueden influir en los requerimientos. 

Los entrevistadores eficaces tienen dos caracteristicas: 

1 . No tienen prejuicios, evitan ideas preconcebidas sobre los requerimientos y estan dis- 
puestos a escuchar a los stakeholders. Si el stakeholder propone requerimientos sor- 
prendentes, estan dispuestos a cambiar su opinion del sistema. 

2. Instan al entrevistado a empezar las discusiones con una pregunta, una propuesta de 
requerimientos o sugiriendo trabajar juntos en un prototipo del sistema. Decira la gen- 
te «dime lo que quieres» es improbable que cause informacion de utilidad. La mayo- 
ria de la gente encuentra mucho mas facil hablar en un contexto definido en vez de en 
terminos generales. 

La informacion de la entrevistas complementa otras informaciones sobre el sistema de los 
documentos, observaciones de los usuarios, etcetera. Algunas veces, aparte de la informacion 
de los documentos, las entrevistas pueden ser la unica fuente de informacion sobre los re- 
querimientos del sistema. Sin embargo, las entrevistas por si mismas tienden a omitir infor- 
macion esencial, por lo que deberian serusadas al lado de otras tecnicas de obtencion de re- 
querimientos. 

Escenarios 

Normalmente, las personas encuentran mas facil dar ejemplos de la vida real que descripcio- 
nes abstractas. Pueden comprender y criticar un escenario de como podrian interactuar con 
un sistema software. Los ingenieros de requerimientos pueden utilizar la informacion obte- 
nida de esta discusion para formular los requerimientos reales del sistema. 

Los escenarios pueden ser especialmente utiles para agregar detalle a un esbozo de la des- 
cripcion de requerimientos. Son descripciones de ejemplos de las sesiones de interaccion. 
Cada escenario abarca una o mas posibles interacciones. Se han desarrollado varias formas 
de escenarios, cada una de las cuales proporciona diferentes tipos de informacion en diferen- 
tes niveles de detalle sobre el sistema. Utilizar escenarios para describir requerimientos es una 
parte fundamental de los metodos agiles, como iaprogramacion extrema, que se aborda en el 
Capitulo 17. 

El escenario comienza con un esbozo de la interaccion y, durante la obtencion, se agregan 
detalles para crearuna descripcion completa de esta interaccion. De forma general, un esce- 
nario puede incluir: 

1. Una descripcion de lo que esperan el sistema y los usuarios cuando el escenario co- 
mienza. 

2. Una descripcion del flujo normal de eventos en el escenario. 

3. Una descripcion de lo que puede ir mal y como manejarlo. 

4. Informacion de otras actividades que se podrian llevar a cabo al mismo tiempo. 

5. Una descripcion del estado del sistema cuando el escenario termina. 

Es posible llevar a cabo de manera informal la obtencion de requerimientos basada en es- 
cenarios cuando los ingenieros de requerimientos trabajan con los stakeholders en la identi- 
ficacion de escenarios y en la captura de detalles de dichos escenarios. Los escenarios se pue- 
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Flgura 7.5 

Escenario para la 
descarga de articulos 
en el UBSYS. 

den redactar como texto, complementados por diagramas, fotografias de las pantallas, etce- 
tera. De forma alternativa, se puede adoptar un enfoque mas estructurado, como los escena- 
rios de evento o los casos de uso. 

Como ejemplo de escenario de texto sencillo, considere como un usuario del sistema de 
biblioteca LIBSYS puede utilizarel sistema. Se muestra este escenario en la Figura 7.5. El 
usuario desea imprimir una copia personal de un articulo de una revista medica. Esta revista 
hace copias de articulos disponibles gratuitamente para los suscriptores, pero las personas que 
no estan suscritas tienen que pagaruna cantidad por articulo. El usuario conoce el articulo, el 
titulo y la fecha de publicacion. 

Casos de uso 

Los casos de uso son una tecnica que se basa en escenarios para la obtencion de requeri- 
mientos que se introdujeron por primera vez en el metodo Objeiory (Jacobsen et ai., 1993). 
Actualmente se han convertido en una caracteristica fundamental de la notacion de U M L , que 
se utiliza para describir modelos de sistemas orientados a objetos. En su forma mas simple, 
uncaso deuso identificael tipo de interacciony los actores involucrados. Por ejemplo, la Fi- 
gura 7.6 muestra un caso de uso de alto nivel de la funcion de impresion de articulos en el 
LIBSYS descrita en la Figura 7.5. 

La Figura 7.6 ilustra la esencia de la notacion para los casos de uso. Los actores en el pro- 
ceso se representan como figuras delineadas, y cada clase de interaccion se representa como 
una elipse con su nombre. El conjunto de casos de uso representa todas las posibles interac- 
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Figura 7.6 Un caso 
de uso sencillo para 
la impresion 

de artfcuios. Impresidn de artteukas 



ciones a representar en los requerimientos del sistema. La Figura 7.7 extiende el ejemplo del 
L I B S Y S y muestra otros casos de uso en ese entorno . 

Algunas veces existe confusion sobre si un caso de uso es un escenario o, como sugiere 
Fowler (Fowler y Scott. 1 997), un caso de uso encierra un conjunto de escenarios, y cada uno 
de estos es un hilo unico a traves del caso de uso. Si un escenario incluye multiples hilos, ha- 
bra un escenario para la interaccion normal y escenarios adicionales para las posibles excep- 
ciones. 

Los casos de uso identifican las interacciones particulares con el sistema. Pueden serdo- 
cumentadas con texto o vinculadas a modelos UML que desarrollan el escenario en mas 
detalle. Los diagramas de secuencia (introducidos en el Capitulo 6) se utilizan a menudo 
para afiadir informacion a un caso de uso. Estos muestran los actores involucrados en la 
interaccion, los objetos con los que interactuan y las operaciones asociadas con estos ob- 
jetos. 

Como ejemplo de esto, la Figura 7.8 muestra las interacciones involucradas en lautiliza- 
cion del LIBSYS para la descarga e impresion de un articulo. En la Figura 7.8, existen cua- 
tro objetos de clases — Articulo, Formulario, Espacio de trabajo e Impresora — involucradas 
en esta interaccion. La secuencia de acciones es de arriba abajo, y las etiquetas de las fechas 
entre los actores y los objetos indican los nombres de las operaciones. Fundamentalmente, una 
peticion de un articulo por parte de un usuario provoca una peticion de un formulario de de- 
rechos de autor. Una vez que el usuario ha completado el formulario, se descarga el articulo 
y se envia a la impresora. Cuando termina la impresion, se elimina el articulo del espacio de 
trabajo del LIBSYS. 

UML es un estandar dejacto para el modelado orientado a objetos, por lo que los casos 
de uso y la obtencion de requerimientos basada en casos de uso se utilizan cada vez mas 
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para la obtencion de requerimientos. Se analizan otros tipos de modelos U M L en el Capi- 
tulo 8, el cual trata el modelado de sistemas, y en el Capitulo 14, que abordael diseno orien- 
tado a objetos. 

Los escenarios y los casos de uso son tecnicas eficaces para obtener requerimientos para 
los puntos de vista de los interactuadores, donde cada tipo de interaccion se puede represen- 
tar como un caso de uso. Tambien se pueden utilizar conjuntamente con algunos puntos de 
vista indirectos cuando estos reciben resultados (como un informe de gestion) del sistema. Sin 
embargo, debido a que se centran en las interacciones, no son tan eficaces para obtener res- 
tricciones y requerimientos de negocio y no funcionales de alto nivel de puntos de vista indi- 
rectos o para descubrir requerimientos del dominio. 



7.2.2 Etnografia 

Los sistemas software no existen de forma aislada: se utilizan en un contexto social y organi- 
zacional, y los requerimientos de sistemas software se pueden derivar y restringir segun ese 
contexto. A menudo, satisfacer estos requerimientos sociales y organizacionales es critico 
para el exito del sistema. Una razon de por que muchos sistemas software se entregan pero 
nunca se utilizan es que no se tiene en cuenta adecuadamente la importancia de este tipo de 
requerimientos del sistema. 

La etnografia es una tecnica de observacion que se puede utilizar para entender los reque- 
rimientos sociales y organizacionales. Un analista se sumerge por si solo en el entorno labo- 
ral donde se utilizara el sistema. Observa el trabajo diario y anota las tareas reales en las que 
los participantes estan involucrados. El valor de la etnografia es que ayuda a los analistas a 
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descubrir los requerimientos implicitos que reflejan los procesos reales mas que los formales 
en los que la gente esta involucrada. 

A menudo, a la gente le resulta muy dificil articular detalles de su propio trabajo debido a 
que lo asumen como algo completamente natural. Comprenden su propio trabajo pero no su 
relacioncon las demas tareas en laorganizacion. Los factores sociales y organizacionales que 
afectan al trabajo, pero que no son obvios para las personas, es posible que solo queden cla- 
ros cuando se fije en ellos un observador imparcial. 

Suchman (Suchman, 1987) utilizo la etnografia para estudiar el trabajo de oficina y ob- 
servo que las practicas del trabajo real eran mucho mas ricas, mas complejas y mas dina- 
micas que los modelos sencillos supuestos por los sistemas de automatizacion de oficinas. 
La diferencia entre el trabajo supuesto y el real fue la razon mas importante de por que es- 
tos sistemas de oficina no han tenido efectos significativos en la productividad. Otros es- 
tudios etnograficos para la comprension de requerimientos del sistema se han llevado a 
cabo en sistemas de control del trafico aereo (Bentley etal, 1992; Hughes etai, 1993), sa- 
las de control del metro (Heath y Luff, 1992), sistemas financieros y varias actividades de 
diseno (Hughes et al., 1994; Hughes et al.. 1994). En mi propia investigacion, he exami- 
nado metodos de integracion de la etnografia en el proceso de la ingenieria del software vin- 
culandola a los metodos de la ingenieria de requerimientos (Viller y Sommerville, 1999; 
Villery Sommerville, 1998; Villery Sommerville, 2000) y documentando patrones de in- 
teraccion en sistemas cooperatives (Martin etal., 2001; Martin etal., 2002; Martin y Som- 
merville, 2004). 

La etnografia es especialmente efectiva para descubrir dos tipos de requerimientos: 

1 . Los requerimientos quese derivan de la forma en la que la gente trabaja realmente 

mas que de la forma en la que las definiciones de los procesos establecen que deberia 
trabajar. Porejemplo, los controladores del trafico aereo pueden desconectar un siste- 
ma de alerta de conflictos que detecta aviones que cruzan las trayectorias de vuelo, aun 
cuando los procedimientos de control normales especifican que debe utilizarse. Su es- 
trategia de control esta disenada para asegurar que estos aviones se separaran antes de 
que ocurran problemas y consideran que la alarma de alerta de conflictos los distrae 
de su trabajo. 

2 . Los requerimientos que se derivan de la cooperation y conocimiento de las activida- 
des de la gente. Por ejemplo, los controladores del trafico aereo pueden utilizar el co- 
nocimiento del trabajo de otros controladores para predecir el numero de aviones que 
entrara en su sector de control. Despues modifican sus estrategias de control depen- 
diendo del volumen de trabajo pronosticado. Por lo tanto, un sistema automatico de 
control del trafico aereo debe permitira los controladores en un sector tener alguna v i - 
sibilidad del trabajo en los sectores adyacentes. 

La etnografia se puede combinar con la construccion de prototipos (Figura 7.9). La etno- 
grafia suministra informacion al desarrollo del prototipo de forma que se requieren menos ci- 
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clos de refinamiento. Ademas, la construccion de prototipos se centra en la etnografia para 
identificarproblemas y preguntas que se puedan discutirposteriormente con el etnografo. Este 
debe buscar las respuestas a estas preguntas durante la siguiente fase de estudio del sistema 
(Sommerville etal., 1993). 

Los estudios etnograficos pueden revelar los detalles de los procesos criticos que otras tec- 
nicas de obtencion de requerimientos a menudo olvidan. Sin embargo, puesto que se centran 
en el usuario final, este enfoque no es apropiado para descubrir los requerimientos organiza- 
cionales o del dominio. Los estudios etnograficos no siempre pueden identificar nuevas pro- 
piedades que se deban agregar al sistema. Por lo tanto, la etnografia no es un enfoque com- 
plete para la obtencion de requerimientos por si mismo, y debe utilizarse para complementar 
otros enfoques, como el analisis de casos de uso. 

73 Validacion de requerimientos 

La validacion de requerimientos trata de mostrar que estos realmente definen el sistema 
que el cliente desea. Coincide parcialmente con el analisis ya que este implica encontrar 
problemas con los requerimientos. La validacion de requerimientos es importante debido 
a que los errores en el documento de requerimientos pueden conducir a importantes cos- 
ies al repetir el trabajo cuando son descubiertos durante el desarrollo o despues de que el 
sistema este en uso. El coste de arreglar un problema en los requerimientos haciendo un 
cambio en el sistema es mucho mayor que reparar los errores de disefio o los de codifica- 
cion. La razon de esto es que un cambio en los requerimientos normalmente significa que 
el disefio y la implementacion del sistema tambien deben cambiary que este debe probar- 
se nuevamente. 

Durante el proceso de validacion de requerimientos, se deben llevar a cabo verificaciones 
sobre requerimientos en el documento de requerimientos. Estas verificaciones comprenden: 

1. Verificaciones de validez- Un usuario puede pensar que se necesita un sistema para lle- 
var a cabo ciertas funciones. Sin embargo, el razonamiento y el analisis pueden iden- 
tificar que se requieren funciones adicionales o diferentes. Los sistemas tienen diver- 
sos stakeholders con diferentes necesidades, y cualquier conjunto de requerimientos 
es inevitablemente un compromiso en el entorno del stakeholder. 

2 . Verificaciones de consistencia. Los requerimientos en el documento no deben contra- 
decirse. Esto es, no debe haber restricciones o descripciones contradictorias de la mis- 
ma funcion del sistema. 

3. Verificaciones de completitud. El documento de requerimientos debe incluir requeri- 
mientos que definan todas las funciones y restricciones propuestas por el usuario del 
sistema. 

4. Verificaciones de realismo. Utilizando el conocimiento de la tecnologia existente, los 
requerimientos deben verificarse para asegurar que se pueden implementar. Estas ve- 
rificaciones tambien deben tener en cuenta el presupuesto y la confeccion de agendas 
para el desarrollo del sistema. 

5. Verificabilidad. Para reducir la posibilidad de discusiones entre el cliente y el con- 
tratista, los requerimientos del sistema siempre deben redactarse de tal forma que 
sean verificables. Esto significa que debe poder escribir un conjunto de pruebas que 
demuestren que el sistema a entregar cumple cada uno de los requerimientos espe- 
cificados. 
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Pueden utilizarse, en conjunto o de forma individual, varias tecnicas de validacion de re- 
querimientos: 

1. Revisiones de requerimientos. Los requerimientos son analizados sistematicamente 
porun equipo de revisores. Este proceso se trata en la siguiente seccion. 

2. Construction deprototipos En este enfoque de validacion, se muestra un modelo eje- 
cutable del sistema a los usuarios finales y a los clientes. Estos pueden experimentar 
con este modelo para ver si cumple sus necesidades reales. En el Capitulo 17 se estu- 
dia la construccion de prototipos y sus tecnicas. 

3. Generation de casos de prueba. Los requerimientos deben poder probarse. Si las 
pruebas para estos se conciben como parte del proceso de validacion, a menudo reve- 
la los problemas en los requerimientos. Si una prueba es dificil o imposible de dise- 
nar, normalmente significa que los requerimientos seran dificiles de implementary de- 
berian ser considerados nuevamente. Desarrollar pruebas para los requerimientos del 
usuario antes de que se escriba codigo es una parte fundamental de la programacion 
extrema. 

No deben subestimarse los problemas en la validacion de requerimientos. Es dificil de- 
mostrar que un conjunto de requerimientos cumple las necesidades del usuario. Los usuarios 
deben imaginarse el sistema en funcionamiento y como este encajaria en su trabajo. Para los 
informaticos expertos es dificil llevar a cabo este tipo de analisis abstracto, pero para los usua- 
rios del sistema es aun mas dificil. Como consecuencia, rara vez se encuentran todos los pro- 
blemas en los requerimientos durante el proceso de validacion de estos. Es inevitable que haya 
cambios adicionales de requerimientos para corregir las omisiones y las malas interpretacio- 
nes de spues de que el documento de requerimientos haya sido aprobado. 

7.3.1 Revisiones de requerimientos 

Una revision de requerimientos es un proceso manual que involucra a personas tanto de la or- 
ganizacion del cliente como de la del contratista. Ellos verifican el documento de requeri- 
mientos en cuanto a anomalias y omisiones. El proceso de revision se puede gestionar de la 
misma forma que las inspecciones de programas (vease el Capitulo 22). Alternativamente, se 
puede organizar como una actividad mas amplia con diferentes personas que verifican dife- 
rentes partes del documento. 

Las revisiones de requerimientos pueden ser informales o formales. Las informales senci- 
llamente implican que los contratistas deben tratar los requerimientos con tantos stakeholders 
del sistema como sea posible. Es sorprendente la frecuencia con la que finaliza la comunica- 
cion entre los desarrolladores y los stakeholders del sistema despues de la obtencion de re- 
querimientos y que no exista confirmacion de que los requerimientos documentados son real- 
mente lo que dijeron que deseaban los stakeholders. 

Antes de llevar a cabo una reunion para una revision formal, muchos problemas se pueden 
detectar simplemente hablando del sistema con los stakeholders. 

En la revision formal de requerimientos, el equipo de desarrollo debe «conducir» al clien- 
te a traves de los requerimientos del sistema, explicandole las implicacionesde cadarequeri- 
miento. El equipo de revision debe verificar cada requerimiento para la consistencia ademas 
de verificar los requerimientos como un todo para la completitud. Los revisores tambien pue- 
den comprobar la: 

1. Vehflcabilidad. ^Puede probarse el requerimiento de modo realista? 
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2. Comprensibilidad. ^Las personas que adquieren el sistema o los usuarios finales com- 
prenden correctamente el requerimiento? 

3. Rastreabilidad. ^Esta claramente establecido el origen del requerimiento? Puede te- 
ner que volver a la fuente del requerimiento para evaluar el impacto del cambio. La 
rastreabilidad es importante ya que permite evaluar el impacto del cambio en el resto 
del sistema. Se trata esto con mayor detalle en la siguiente seccion. 

4. Adaptabilidad ^Es adaptable el requerimiento? Es decir, ^puede cambiarse el reque- 
rimiento sin causar efectos de gran escala en los otros requerimientos del sistema? 

Los conflictos, contradicciones, errores y omisiones en los requerimientos deben ser se- 
fialados por los revisores y registrarse formalmente en el informe de revision. Queda en los 
usuarios, la persona que adquiere el sistema y el desarrollador de este negociaruna solucion 
para estos problemas identificados. 

7.4 Gestion de requerimientos 

Los requerimientos para sistemas software grandes son siempre cambiantes. Una razon es que 
estos sistemas normalmente se desarrollan para abordar problemas «traviesos» (como se vio 
en el Capitulo 2). Debido a que el problema no puede definirse completamente, es muy pro- 
bable que los requerimientos del software sean incompletos. Durante el proceso del softwa- 
re, la comprension del problema porparte de los stakeholders esta cambiando constantemen- 
te. Estos requerimientos deben entonces evolucionar para reflejar esta perspectiva cambiante 
del problema. 

Ademas, una vez que un sistema se ha instalado, inevitablemente surgen nuevos requeri- 
mientos. Es dificil para los usuarios y clientes del sistema anticipar que efectos tendra el sis- 
tema nuevo en la organizacion. Cuando los usuarios finales tienen experiencia con un siste- 
ma, descubren nuevas necesidades y prioridades: 

1 . Normalmente, los sistemas grandes tienen una comunidad de usuarios diversa donde 
los usuarios tienen diferentes requerimientos y prioridades. Estos pueden contrade- 
cirse o estar en conflicto. Los requerimientos finales del sistema son inevitablemente 
un compromiso entre ellos y, con la experiencia, a menudo se descubre que la ayuda 
suministrada a los diferentes usuarios tiene que cambiarse. 

2. Las personas que pagan por el sistema y los usuarios de este raramente son la misma 
persona. Los clientes del sistema imponen requerimientos debido a las restricciones or- 
ganizacionales y de presupuesto. Estos pueden estar en conflicto con los requerimien- 
tos de los usuarios finales y, despues de la entrega, pueden tener que anadirse nuevas 
caracteristicas de apoyo al usuario si el sistema tiene que cumplir sus objetivos. 

3. El entornode negociosy tecnico del sistema cambia despues de la instalacion, y estos 
cambios se deben reflejar en el sistema. Se puede introducir nuevo hardware, puede ser 
necesario que el sistema interactive con otros sistemas, las prioridades de negocio pue- 
den cambiar con modificaciones consecuentes en la ayuda al sistema, y puede haber una 
nueva legislacion y regulaciones que deben ser implementadas por el sistema. 

La gestion de requerimientos es el proceso de comprender y controlar los cambios en los 
requerimientos del sistema. Es necesario mantenerse al tanto de los requerimientos particula- 
res y mantener vinculos entre los requerimientos dependientes de forma que se pueda evaluar 
el impacto de los cambios en los requerimientos. Hay que establecer un proceso formal para 
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implementar las propuestas de cambios y vincular estos a los requerimientos del sistema. El 
proceso de gestion de requerimientos deberia empezar en cuanto este disponible una version 
preliminar del documento de requerimientos, pero se deberia empezar a planificar como ges- 
tionar los requerimientos que cambian durante el proceso de obtencion de requerimientos. 

7.4.1 Requerimientos duraderos y vol a tiles 

La evolucion de los requerimientos durante el proceso de ingenieria de requerimientos y des- 
pues de que un sistema este en uso es inevitable. El desarrollo de requerimientos software cen- 
tra su atencion en las capacidades de este, los objetivos del negocio y otros sistemas de la or- 
ganizacion. Conforme se va desarrollando la definicion de los requerimientos, normalmente 
tiene una mejor comprension de las necesidades de los usuarios. Esto retroalimenta la infor- 
macion del usuario, quien puede entonces proponer un cambio en los requerimientos (Figura 
7.10). Ademas, especificary desarrollarun sistema grande puede llevarvarios afios. Durante 
ese tiempo, el entorno del sistema y los objetivos del negocio cambian, y los requerimientos 
evolucionan para reflejar esto. 

Desde una perspectiva evolutiva, los requerimientos se dividen en dos clases: 

1 . Requerimientos duraderos. Son requerimientos relativamente estables que se derivan 
de la actividad principal de la organizacion y que estan relacionados directamente con 
el dominio del sistema. Porejemplo, en un hospital siempre habra requerimientos que 
se refieren a los pacientes, medicos, enfermeras y tratamientos. Estos requerimientos 
se pueden derivar de los modelos del dominio que muestran las entidades y relaciones 
que caracterizan un dominio de aplicacion (Easterbrook, 1993; Prieto-Diaz y Arango, 
1991). 

2. Requerimientos voldtiles. Son requerimientos que probablemente cambian durante el 
proceso de desarrollo del sistema o despues de que este se haya puesto en funciona- 
miento. Un ejemplo serian los requerimientos resultantes de las politicas guberna- 
mentales sobre sanidad. 

Harkery otros (Harker et al., 1993) han indicado que los requerimientos volatiles se divi- 
den en cinco clases. Utilizando estas como base, se ha desarrollado la clasificacion mostrada 
en la Figura 7.1 1. 



7.4.2 Planlflcacldn de la gestion de requerimientos 

La planificacion es una primera etapa esencial del proceso de gestion de requerimientos. La 
gestion de requerimientos tiene un coste elevado. Para cada proyecto, la etapa de planifica- 



Figura 7.10 

Evolucion de los 
requerimientos. 



Comprensi6n 




inicial 




del problema 




1 




Requerimientos 




iniciales 





Cambio en la 
comprensidn 
del problema 

1 | ' 

Requerimientos 
cambiados 



*■ 

Tiempo 



148 CAPITUL07 • Procesos de la ingenieria de requerimientos 



toinoM^ijtt*opOTlia^piiiaiMit Po f < )wnpki v cnlMrit- 
terwhoepfcalarioe, el pay del cu tdi do del peqente puede 

cambiaryatfrequerirunt nBar fdantodgei^^ 
• i 



Ret|iMfimwrtM que e r n e rgui tf fncrefnentMM It compren- 
skio <M cSente en d dramRo del satternei 0 pfoceso de <fi- 
sefto puede temtv requerimientDS emenerrtu 



RB qm rim(tB>ot que aon neuKade de le tatoduratin dt) sie- 
terra infarmatico. E*a mtrod H Cd dn puedi cantbiar hn pro- 
cesos de to ofyncad6o y deniTPtir ngm> tomas de tn- 
baiar que gtnenn mmot raquerinilentQi ihl adtema. 



Flgura 7.11 

Clasificacion de los 

requerimientos 

volatiles. 



RequerlmienteM qu* depeoden da ilmmn partjeutares o 

tm dMmo* cambian, k» nojuarimianlM de eompatibflidad 
de) ststMna encarajado o < 
<pie cwnhlaf 



cion establece el nivel de detalle necesario en la gestion de requerimientos. Durante la etapa 
de gestion de requerimientos, habra que decidir sobre: 

1. La identification de requerimientos. Cada requerimiento se debe identificar de forma 
unica de tal forma que puedan ser remitidos por otros requerimientos de manera que 
pueda utilizarse en las evaluaciones de rastreo. 

2. Un proceso de gestion del cambio. Este es el conjunto de actividades que evaluan el 
impacto y coste de los cambios. Se tratacon mayor detalle este proceso en la seccion 
siguiente . 

3. Politicas de rastreo. Estas politicas definen las relaciones entre los requerimientos, y 
entre estos y el diseno del sistema que se debe registrar y la manera en que estos re- 
gistros se deben mantener. 

4. Ayuda de herramientas CASE. La gestion de requerimientos comprende el procesa- 
miento de grandes cantidades de informacion sobre los requerimientos. Las herra- 
mientas que se pueden utilizar van desde sistemas de gestion de requerimientos espe- 
cializados hasta hojas de calculo y sistemas sencillos de bases de datos. 

Existen muchas relaciones entre los requerimientos y entre estos y el diseno del sistema. 
Tambien existen vinculos entre los requerimientos y las razones fundamentales por las que es- 
tos se propusieron. Cuando se proponen cambios, se debe rastrear el impacto de estos cambios 
en los otros requerimientos y en el diseno del sistema. El rastreo es una propiedad de la espe- 
cificacion de requerimientos que refleja la facilidad de encontrar requerimientos relacionados. 

Existen tres tipos de informacion de rastreo que pueden ser mantenidos: 

1. La information de rastreo de la fuente vincula los requerimientos con los stakeholders 
que propusieron los requerimientos y la razon de estos. Cuando se propone un cambio, 
esta informacion se utilizapara encontrar y consultar a los stakeholders sobre el cambio. 

2. La information de rastreo de los requerimientos vincula los requerimientos depen- 
dientes en el documento de requerimientos. Esta informacion se utilizapara evaluar 
como es probable que muchos requerimientos se vean afectados por un cambio pro- 
puesto y la magnitud de los cambios consecuentes en los requerimientos. 
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3. La information de rastreo del diseho vincula los requerimientos a los modulos del di- 
seflo en los cuales son implemeniados. Esta informacion se utiliza para evaluarel im- 
pacto de los cambios de los requerimientos propuestos en el diseflo e implementacion 
del sistema. 

A menudo, la informacion de rastreo se representa utilizando matrices de rastreo, las cua- 
les relacionan los requerimientos con los stakeholders, con los modulos del diseflo o los re- 
querimientos entre ellos. En una matriz de rastreo de requerimientos, cada requerimiento se 
representa en una fila y en una columna de la matriz. Cuando existen dependencias entre di- 
ferentes requerimientos, estas se registran en la celda en la interseccion fila/columna. 

La Figura 7.12 muestra una matriz de rastreo sencilla que registra las dependencias entre 
los requerimientos. Una «D» en la interseccion fila/columna ilustra que el requerimiento en 
la fila depende del requerimiento seflalado en la columna; una «R» significa que existe algu- 
na olra relacion mas debil entre los requerimientos. Por ejemplo, ambos pueden definir los re- 
querimientos para partes del mismo subsistema. 

Las matrices de rastreo pueden utilizarse cuando se tiene que gestionar un numero peque- 
flo de requerimientos, pero son dificiles de manejar y caras de mantener para sistemas gran- 
des con muchos requerimientos. Para estos sistemas, se deberia captar la informacion de ras- 
treo en una base de datos de requerimientos en la que cada requerimiento este explicitamente 
vinculado a los requerimientos relacionados. De esta forma, se puede evaluarel impacto de 
los cambios utilizando las facilidades de exploracion de la base de datos. Se pueden generar 
automaticamente matrices de rastreo de la base de datos. 

La gestion de requerimientos necesita ayuda automatizada; las herramientas CASE para 
esto deben elegirse durante la fase de planificacion. Se precisan herramientas de ayuda para: 

1. Almacenar requerimientos. Los requerimientos deben mantenerse en un almacen de 
datos seguro y administrado que sea accesible a todos los que esten implicados en el 
proceso de ingenieria de requerimientos. 

2. Gestionar el cambio. Este proceso (Figura 7.13) se simplifica si esta disponible una 
herramienta de ayuda. 
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3 . Gestionar el rastreo. Como se indico anteriormente, las herramientas de ayuda para 
el rastreo permiten que se descubran requerimientos relacionados. Algunas herra- 
mientas utilizan tecnicas de procesamiento del lenguaje natural para ayudarle a des- 
cubrirposibles relaciones entre los requerimientos. 

Para sistemas pequefios, es posible que no sea necesario utilizar herramientas de gestion 
de requerimientos especializadas. El proceso de gestion de requerimientos puede llevarse a 
cabo utilizando los recursos disponibles en los procesadores de texto, hojas de calculo y ba- 
ses de datos en PC. Sin embargo, para sistemas grandes, se requieren herramientas de ayuda 
mas especializadas. En el sitio web del libro he incluido enlaces a herramientas de gestion de 
requerimientos como DOORS y RequisitePro. 

7.4.3 Gestion del camblo de los requerimientos 

La gestion del cambio de los requerimientos (Figura 7.13) se debe aplicar a todos los cam- 
bios propuestos en los requerimientos. La ventaja de utilizar un proceso formal para gestio- 
nar el cambio es que todos los cambios propuestos son tratados de forma consistente y que 
los cambios en el documento de requerimientos se hacen de forma controlada. Existen tres 
etapas principales en un proceso de gestion de cambio: 

1. Andlisis del problema y especiflcacion del cambio. E 1 proceso empieza con la identi- 
ficacion de un problema en los requerimientos o, algunas veces, con una propuesta de 
cambio especifica. Durante esta etapa, el problema o la propuesta de cambio se anali- 
za para verificar que esta es valida. Los resultados del analisis se pasan al solicitante 
del cambio, y algunas veces se hace una propuesta de cambio de requerimientos mas 
especifica. 

2. Andlisis del cambio y calculo de costes. E 1 efecto de un cambio propuesto se valora 
utilizando la informacion de rastreo y el conocimiento general de los requerimientos 
del sistema. El coste de hacer un cambio se estima en terminos de modificaciones al 
documento de requerimientos y, si es apropiado, al diseno e implementacion del sis- 
tema. Una vezque este analisis se completa, se tomauna decision sobre si se continua 
con el cambio de requerimientos. 

3. Implementacion del cambio. Se modifica el documento de requerimientos y, en su 
caso, el diseno e implementacion del sistema. Debe organizarel documento de reque- 
rimientos de modo que pueda hacer cambios en el sin tener que hacer grandes reorga- 
nizaciones o redactar nuevamente gran cantidad del mismo. Como sucede con los pro- 
gramas, los cambios en los documentos se llevan a cabo minimizando las referencias 
externas y haciendo las secciones del documento tan modulares como sea posible. De 
esta manera, se pueden cambiary reemplazar secciones individuales sin afectar a otras 
partes del documento. 

Si se requiere de forma urgente un cambio en los requerimientos del sistema, existe siem- 
pre la tentacion de hacer ese cambio al sistema y entonces modificar de forma retrospectiva 
el documento de requerimientos. Esto conduce casi inevitablemente a que la especificacion 
de requerimientos y la implementacion del sistema se desfasen. Una vezque sehanhecho los 
cambio en el sistema, los del documento de requerimientos se pueden olvidar o se hacen de 
forma que no concuerdan con los cambios del sistema. 

Los procesos de desarrollo iterativo, como la programacion extrema, se han disenado para 
hacer frente a los requerimientos que cambian durante el proceso de desarrollo. En estos pro- 
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cesos, cuando un usuario propone un cambio en los requerimientos, no se hace a traves de un 
proceso formal de gestion del cambio. Mas bien, el usuario tiene que establecer la prioridad 
del cambio y, si es de alta prioridad, decidir que caracteristica del sistema que rue planifica- 
da para la siguiente iteracion deberia abandonarse. 



me 



PUNTOS CLAVE 

• El proceso de ingenieria de requerimientos incluye un estudio de viabilidad, asi como la obtencion, analisis, 
especificacion, validacion y gestion de requerimientos. 

• La obtencion y analisis de requerimientos es un proceso iterativo que puede ser representado como una es- 
piral de actividades - el descubrimiento de requerimientos, la clasif icacion y organizacion de requerimientos, 
(a negociacion de requerimientos y ta documentacion de requerimientos. 

• Los diferentes stakeholders del sistema tienen requerimientos diferentes. Por lo tanto, todos los sistemas 
complejos deben analizarse desde varios puntos de vista. Estos pueden ser personas u otros sistemas que 
interactuancon et sistema a especificar, stakeholders afectados por el sistema, o puntos de vista del dominio 
que restringen los requerimientos. 

• Los factores sociales y organizacion a les tienen una fuerte influencia sobre los requerimientos del sistema y 
pueden determinar si el software realmente se utiliza. 

• La validacion de requerimientos es el proceso de verificar los requerimientos en cuanto a validez, consisten- 
cia, completitud, realismo yverificabilidad. Las principals tecnicas para la validacion son las revisiones de los 
requerimientos y la construccionde prototipos. 

• Los cambios en tos negocios, organizacionales y tecnicos inevitablemente conducen a cambios en los reque- 
rimientos de un sistema software. La gestion de requerimientos es el proceso de gestionary controlar estos 
cambios. 

• El proceso de gestion de requerimientos incluye la gestion de la planif icacion. en la cual se disehan las polf- 
ticas y procedimientos para la gestion de requerimientos, y la del cambio, en la que usted analiza los cambios 
propuestos en los requerimientos y evalua su impacto. 



«Requirements engineering)). Este numero especial incluye dos articulos que se centran en la ingenieria de reque- 
rimientos para dominios particulares (coches y dispositivos medicos) que ofrecen perspectivas interesantes en los 
procesos de la ingenieria de requerimientos en estas areas. [lEEESoftware, 20 (1), enero-febrero de 2003.I 

Mastering the Requirements Process. Un libro interesante dirigido a los ingenieros de requerimientos que ejercen. 
Da consejos especificos para desarrollarun proceso de ingenieria de requerimientos efectivo. (S. Robertson y J. Ro- 
bertson, 1999, Addison- Wesley.) 
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Requirements Engineering: Proceses and Techniques. Este libro incluye una vision mas detallada de las actividades 
del proceso de ingenieria de requerimientos y analiza el metodo VORD y su aplicacion. (G. Kotonya e I. Sommervi- 
lle, 1998, John Wiley & Sons.) 



EJERCICIOS 



7.1 Mencione quienes podrian ser los stakeholders en un sistema de registro de estudiantes universitarios. Ex- 
plique por que es casi inevitable que los requerimientos de diferentes stakeholders entren en conflicto de 
alguna forma. 

72 Un sistema software se desarrolla para gestionar los registros de los pacientes que ingresan en una clinica 
para tratamiento. Los registros incluyen anotaciones de todos los controles habituates a los pacientes (tem- 
peratura, tension arterial, etc.), los tratamientos dados, las reacciones de los pacientes, etcetera. Despues 
del tratamiento, los registros de su estancia se envian al doctor del paciente, quien mantiene su historial 
clinico completo. Identifique los puntos de vista principales que se pueden tener en cuenta en la especifi- 
cacion del sistema y organ ice los utilizando un diagrama dejerarquiade puntos de vista. 

73 Para tres de los puntos de vista identificados en el sistema de biblioteca, LIBSYS (Figura 7.4), mencione tres 
requerimientos que podrian ser sugeridos por los stakeholders relacionados con ese punto de vista. 

7.4 El sistema LIBSYS tiene que incluir soporte para la catalogacion de nuevos documentos donde el catalogo 
del sistema puede ser distribuido a t raves de varias maquinas.^Cualesson probablemente lostipos mas im- 
portantes de requerimientos no funcionales relacionados con (os servicios de catalogacion? 

7S Utilizando su conocimiento de como funciona un cajero automatico de un banco, desarrolle un conjunto de 
casos de uso que podrian servir como una base para entender los requerimientos de un sistema de un ca- 
jeroautomatico. 

7.6 De un ejemplo de un tipo de sistema en el que los factores sociales y politicos pueden influir fuertemente 
en los requerimientos del sistema. Explique por que estos factores son importantes en el ejemplo. 

7.7 ^Quienes deberi an estar implicados en la revision de requerimientos? Establezca un modelo del proceso que 
muestre como se puede organizar una revision de requerimientos. 

7.8 ^Porquelas matrices de rastreo son dificiles de manejar cuando existen muchos requerimientos en el sis- 
tema? Disehe un mecanismo de estructuracion de requerimientos, basado en puntos de vista, que pueda 
ayudar a reducirel tamaho del problema. 

73 Cuando se hacen cambios de emergencia en los sistemas, el sistema software puede tener que modificar- 
se antes de que los cambios en los requerimientos se aprueben. Sugiera un modelo de proceso para hacer 
estas modificaciones que asegure que el documento de requerimientos y la Implementacion del sistema no 
sean incompatibles. 

7.10 Su compania utiliza un metodo de analisis estandar que normalmente se aplica en todos los analisis de re- 
querimientos. En su trabajo, comprueba que este metodo no puede representar factores sociales que son 
significativos en el sistema que usted analiza. Le sehala esto a su jefe, quien le indica claramente que el es- 
tandar debe seguirse. Mencione que debe hacer en talsituacion. 
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Objetivos 

El objetivo de este capitulo es introducir varios modelos de 
sistemas que pueden desarrollarse durante el proceso de 
ingenieria de requerimientos. Cuando haya leido este capitulo: 

• comprendera por que es importante establecer los limites de 
un sistema y modelar su contexto; 

• comprendera los conceptos del modelado del 
comportamiento, modelado de los datos y modelado de los 
objetos; 

• habra sido introducido en alguna de las notaciones definidas 
en el Lenguaje Unificado de Modelado (UML) y como estas 
notaciones pueden usarse para desarrollar modelos de 
sistemas. 

Contenidos 

8.1 Modelos de contexto 

8.2 Modelos de comportamiento 

8.3 Modelos de datos 

8.4 Modelos de objetos 

8.5 Metodos estructurados 
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Los requerimientos del usuario deberian redactarse en lenguaje natural debido a que tienen 
que ser comprendidos por personas que no son tecnicos expertos. Sin embargo, pueden ex- 
presarse requerimientos del sistema mas detallados de forma mas tecnica. Una tecnica am- 
pliamente usada es documentar la especificacion del sistema como un conjunto de modelos 
del sistema. Estos modelos son representaciones graficas que describen los procesos del ne- 
gocio, el problema a resolver y el sistema que tiene que ser desarrollado. Debido a las repre- 
sentaciones graficas usadas, los modelos son a menudo mas comprensibles que las descrip- 
ciones detalladas en lenguaje natural de los requerimientos del sistema. Ellos constituyen 
tambien un puente importante entre el proceso de analisis y disefto. 

Pueden usarse modelos en el proceso de analisis para comprender el sistema existente que 
debe ser reemplazado o mejorado, o para especificarel nuevo sistema que sea requerido. Pue- 
den desarrollarse diferentes modelos para representar el sistema desde diferentes perspecti- 
vas. Por ejemplo: 

1 . Una perspectiva externa, en la que se modela el contexto o entorno del sistema. 

2. Una perspectiva de comportamiento, en la que se modela el comportamiento del sis- 
tema. 

3. Una perspectiva estructural, en la que se modela la arquitectura del sistema o la es- 
tructura de los datos procesados por el sistema. 

Estas tres perspectivas se tratan en este capitulo y tambien se estudia el modelado de ob- 
jetos, que combina, de alguna manera, el modelado del comportamiento y de la estructura. 

El aspecto mas importante de un modelo del sistema es que omite los detalles. Un mode- 
lo del sistema es una abstraccion del sistema que se esta estudiando en lugar de una repre- 
sentacion alternativa de ese sistema. Idealmente, una representation de un sistema deberia 
mantener toda la informacion sobre la entidad que se esta representando. Una abstraction 
simplificay resaltade forma deliberada las caracteristicas mas relevantes. Por ejemplo, en el 
caso improbable de que este libro fuese publicado porcapitulos en un periodico, lapresenta- 
cion en este caso seria una abstraccion de los puntos clave del libro. Si fuese traducido del in- 
gles al italiano, esta podria ser una representacion alternativa. La intencion del traductor de- 
beria ser mantener toda la informacion tal y como se presenta en ingles. 

Diferentes tipos de modelos del sistema se basan en distintas aproximaciones de abstrac- 
cion. Un modelo de flujo de datos (por ejemplo) se centra en el flujo de datos y las transfor- 
maciones funcionales sobre esos datos. Se omiten los detalles de las estructuras de datos. Por 
el contrario, un modelo de entidades de datos y sus relaciones documentan las estructuras de 
datos del sistema en lugar de su funcionalidad. 

Ejemplos de tipos de modelos del sistema que podrian crearse durante el proceso de ana- 
lisis son: 

1. Un modelo de flujo de datos. Los modelos de flujo de datos muestran como se proce- 
san los datos en el sistema en diferentes etapas. 

2. Un modelo de composition. Un modelo de composicion o agregacion muestra como 
las entidades del sistema estan compuestas por otras entidades. 

3. Un modelo arquitectonico. Los modelos arquitectonicos muestran los principales sub- 
sistemas que componen un sistema. 

4. Un modelo de clasiflcacidn. Los diagramas de clases/herencia de objetos muestran 
como las entidades tienen caracteristicas comunes. 

5. Un modelo de estimulo-respuesta. Un modelo de estimulo respuesta o diagrama de 
transition de estados muestra como reacciona el sistema a eventos internos y ex- 
ternos. 
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Todos estos tipos de modelos se tratan en este capitulo. Siempre que es posible, se usan 
notaciones del Lenguaje Unificado de Modelado (UML), que se ha convertido en un len- 
guaje de modelado estandar para el modelado orientado a objetos (Booch ex al., 1999; 
Rumbaugh etal., 1999a). Se usan notaciones intuitivas simples para la descripcion del mo- 
delo en donde UML no incluye las notaciones adecuadas. Se esta desarrollando una nueva 
version de U M L (UML 2.0), pero no estaba disponible en el momento de escribir este ca- 
pitulo. Sin embargo, la notacion UML utilizada aqui es compatible probablemente con 
UML 2.0. 



Modelos de contexto 

En una de las primeras etapas de la obtencion de requerimientos y del proceso de analisis se 
deben definir los Hmites del sistema. Esto comprende trabajar conjuntamente con los stake- 
holders del sistema para distinguir lo que es el sistema y lo que es el entorno del sistema. Us- 
ted deberia tomar estas decisiones al inicio del proceso para delimitar los costes del sistema 
y el tiempo necesario para el analisis. 

En algunos casos, el limite entre un sistema y su entorno esta relativamente claro. Por ejem- 
plo, en el caso de que un sistema automatico reemplace a un sistema existente manual o com- 
puterizado, el entorno del nuevo sistema es normalmente el mismo que el entorno del siste- 
ma existente. En otros casos, hay mas flexibilidad, y usted decide lo que constituye el limite 
entre el sistema y su entorno durante el proceso de ingenieria de requerimientos. 

Por ejemplo, suponga que esta desarrollando la especificacion para el sistema de bi- 
blioteca LIBSYS. Recuerde que este sistema pretende entregar versiones electronicas de 
material con derechos de autora los usuarios de computadoras. A continuacion los usua- 
rios pueden imprimir copias personales del material. Cuando desarrolla la especificacion 
para este sistema, usted tiene que decidir si otros sistemas de bases de datos de bibliotecas 
tales como catalogos de bibliotecas estan dentro de los Hmites del sistema. Si lo estan, en- 
tonces puede permitir el acceso al sistema a traves de la interfaz de usuario del catalogo; 
si no lo estan, entonces los usuarios sufriran la incomodidad de tenerse que mover de un 
sistema a otro. 

Ladefiniciondeun limite del sistema no es una decision arbitraria. Aspectos socialesy or- 
ganizational pueden implicar que la situacion de los Hmites de un sistema puedan ser de- 
terminados por factores no tecnicos. Por ejemplo, un limite de un sistema puede situarse de 
forma que el proceso de analisis solo se pueda llevar a cabo en un lugar; puede ser elegido 
para que un gestor problematico no necesite ser consultado; puede situarse para que el coste 
del sistema se incremente, y la division del desarrollo del sistema debe, por lo tanto, expan- 
dirse al diseno e implementacion del sistema. 

Una vez que se han tornado algunas decisiones sobre los Hmites del sistema, parte de (a ac- 
tividad del analisis es la definicion de ese contexto y de las dependencias que el sistema tie- 
ne sobre su entorno. Normalmente, laproduccion de un modelo arquitectonico sencillo es el 
primer paso en esta actividad. 

La Figura 8.1 es un modelo arquitectonico que ilustra la estructura del sistema de infor- 
macion que incluye una red de cajeros automaticos. Los modelos arquitectonicos de alto ni- 
vel se expresan normalmente como sencillos diagramas de bloques en donde cada subsiste- 
ma se representa por un rectangulo con nombre, y las lineas indican asociaciones entre los 
subsistemas. 
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En la Figura 8.1, podemos ver que cada ATM (cajero automatico) esta conectado a una 
base de datos de cuentas, a un sistema de contabilidad de la sucursal, a un sistema de seguri- 
dad y a otro de mantenimiento de los cajeros. El sistema tambien esta conectado a una base 
de datos de uso comun que monitoriza como se usa la red de ATMs y tambien esta conecta- 
do a un sistema auxiliar local de una sucursal. Este sistema auxiliar proporciona servicios ta- 
les como copias de seguridade impresion. Estos,por lo tanto, no necesitan incluirseenelpro- 
pio sistema ATM. 

Los modelos arquitectonicos describen el entorno de un sistema. Sin embargo, no mues- 
tran las relaciones entre otros sistemas del entorno y el sistema que se esta especificando. Los 
sistemas extemos podrlan producir o consumir datos del sistema. Podrlan compartir datos con 
el sistema, o podrlan ser conectados directamente, conectados a traves de una red o no estar 
conectados. Podrlan estar flsicamente en el mismo lugaro localizados en edificios diferentes. 
Todas estas relaciones podrlan afectar a los requerimientos del sistema que se esta definien- 
do y deben tenerse en cuenta. 

Por lo tanto, los modelos arquitectonicos sencillos normalmente se complementan con 
otros modelos, tales como modelos de procesos, que muestran las actividades de los proce- 
sos soportadas por el sistema. Los modelos de flujo de datos (descritos en la seccion siguien- 
te) tambien pueden usarse para mostrar los datos que son transferidos entre el sistema y otros 
sistemas de su entorno. 

La Figura 8.2 ilustra un modelo de proceso de adquisicion de equipos de una organizacion. 
Esto implica especificar el equipo requerido, buscar y elegir a los proveedores, pedir el equi- 
po, recibir los equipos a su llegada y a continuacion verificarlos. Cuando especifique el so- 
porte informatico para este proceso, usted tiene que decidir cuales de esas actividades seran 
realmente informatizadas. El resto de las actividades estan fuera de los llmites del sistema. En 
la Figura 8.2, la llnea discontinua encierra las actividades que estan dentro de los llmites del 
sistema. 



82 Modelos de comportamiento 

Los modelos de comportamiento se utilizan para describir el comportamiento del sistema en 
su totalidad. Aqul se analizan dos tipos de modelos de comportamiento: modelos de flujo de 
datos, que modelan el procesamiento de los datos en el sistema, y modelos de maquinas de 
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estado, que modelan como el sistema reacciona a los eventos. Estos modelos pueden usarse 
de forma separada o conjuntamente, dependiendo del tipo de sistema que se este desarro- 
llando. 

La mayoria de los sistemas de negocio estan fundamentalmente dirigidos por los datos. Es- 
tan controlados por las entradas de datos al sistema con relativamente poco procesamiento de 
eventos externos. Un modelo de flujo de datos puede ser todo lo que se necesite para repre- 
sentar el comportamiento de estos sistemas. Por el contrario, los sistemas de tiempo real a me- 
nudo estan dirigidos por eventos con un minimo procesamiento de datos. Un modelo de ma- 
quina de estados (analizado en la Seccion 8.2.2) es la forma mas efectiva de representar su 
comportamiento. Otras clases de sistemas pueden estar dirigidas tanto por datos como por 
eventos. En estos casos usted puede desarrollar ambos tipos de modelos. 



8.2.1 Modelos de flujo de datos 

Los modelos de flujo de datos son una forma intuitiva de mostrarcomo los datos son proce- 
sados por un sistema. A nivel de analisis, deberian usarse para modelar la forma en la que los 
datos son procesados en el sistema existente. El uso de modelos de flujo de datos para anali- 
sis comenzo a usarse ampliamente despues de la publicacion del libro de DeMarco (DeMar- 
co, 1978) sobre analisis de sistemas estructurados. Estos modelos son una parte intrmseca de 
los metodos estructurados que han sido desarrolladosapartirde estetrabajo. Lanotacionusa- 
da en ellos representa el procesamiento funcional (rectangulos redondeados), los almacenes 
de datos (rectangulos) y el flujo de datos entre funciones (flechas etiquetadas). 
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Los modelos de flujo de datos se utilizan para mostrarcomo fluyen los datos a traves de 
una secuencia de pasos de procesamiento. Por ejemplo, un paso de procesamiento podria ser 
filtrar registros duplicados en una base de datos de clientes. Los datos se transforman en cada 
paso antes de moverse a la siguiente etapa. Estos pasos de procesamiento o transformaciones 
representan procesos software o funciones cuando los diagramas de flujo de datos se utilizan 
paradocumentarundiseflo software. Sin embargo, enunmodelo de analisis, el procesamiento 
se puede llevar a cabo por las personas o por las computadoras. 

Un modelo de flujo de datos, que muestra los pasos que comprende el procesamiento de 
un pedido de productos (tales como equipamiento informatico) en una organizacion, se ilus- 
tra en la Figura 8.3. Este modelo particular describe el procesamiento de datos en la actividad 
Colocarel pedido del equipamiento en el modelo completo del proceso mostrado en la Fi- 
gura 8.2. El modelo muestra como el pedido para los productos fluye desde un proceso a otro. 
Tambien muestra los almacenes de datos ( Fichero de pedidos y Fichero de presupuesto) 
que estan implicados en este proceso. 

Los modelos de flujo de datos son valiosos debido a que realizan un seguimiento y docu- 
mentan como los datos asociados con un proceso particular fluyen a traves del sistema, y esto 
ayuda a los analistas a comprender el proceso. Los diagramas de flujo de datos tienen la ven- 
taja de que, a diferencia de otras notaciones de modelado, son sencillos e intuitivos. Normal- 
mente es posible explicarlos a los usuarios potenciales del sistema, quienes pueden entonces 
participar en la validacion del analisis. 

En principio, el desarrollo de modelos tales como modelos de flujo de datos deberia ser 
un proceso «descendente». En este ejemplo, esto podria implicarque deberia comenzarse 
analizando el proceso de adquisicion de equipamiento en su totalidad. A continuacion se 
seguiria con el analisis de subprocesos tales como el de solicitud de pedidos. En la practi- 
ca, el analisis nunca se hace asi. Se analizan varios niveles al mismo tiempo. Los modelos 
de bajo nivel pueden desarrollarse primero y despues abstraerse para crearun modelo mas 
general. 

Los modelos de flujo de datos muestran una perspectiva funcional en donde cada trans- 
formacion representa un unico proceso o funcion. Son particularmente utiles durante el ana- 
lisis de requerimientos ya que pueden usarse para mostrar el procesamiento desde el princi- 
pio hasta el final en un sistema. Es decir, muestra la secuencia completa de acciones que tienen 
lugar a partir de una entrada que se esta procesando hasta la correspondiente salida que cons- 
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tituye la respuesta del sistema. La Figura 8.4 ilustra este uso de los diagramas de flujo de da- 
tos. Este es un diagrama del procesamiento que tiene lugar en el sistema de bomba de insuli- 
na introducido en el Capitulo 3. 

8.2.2 Modelos de maquina de estados 

Un modelo de maquina de estados describe como responde un sistema a eventos internos o 
extemos. El modelo de maquina de estados muestra los estados del sistema y los eventos que 
provocan las transiciones de un estado a otro. No muestra el flujo de datos dentro del siste- 
ma. Este tipo de modelo se utiliza a menudo para modelar sistemas de tiempo real debido a 
que estos sistemas suelen estar dirigidos por estimulos procedentes del entorno del sistema. 
Por ejemplo, el sistema de alarma de tiempo real explicado en el Capitulo 13 responde a es- 
timulos de sensores de movimiento, sensores de apertura de puertas, etcetera. 

Los modelos de maquina de estados son una parte integral de los metodos de diseno de 
tiempo real tales como los propuestos por Ward y Mellor (Ward and Mellor, 1985), y Harel 
(Harel, 1987; Harel, 1988). El metodo de Harel usa una notacion denominada diagramas de 
estado que fue la base para la notacion del modelado de maquina de estados en UML. 

Un modelo de maquina de estados de un sistema supone que, en cualquiermomento, el sis- 
tema esta en uno de varios estados posibles. Cuando se recibe un estimulo, este puede dispa- 
rar una transicion a un estado diferente. Por ejemplo, un sistema de control de una valvula 
puede moverse desde un estado « Valvula abierta» a un estado « Valvula cerrada» cuando se 
reciba una orden (el estimulo) del operador. 

Esta aproximacion para el modelado de sistemas se ilustra en la Figura 8.5. Este diagrama 
muestra un modelo de maquina de estados de un sencillo horno microondas equipado con bo- 
tones para fijar la potencia y el temporizador y para iniciar el sistema. Los hornos microon- 
das reales son actualmente mucho mas complejos que el sistema descrito aqui. Sin embargo, 
este modelo incluye las caracteristicas esenciales del sistema. Para simplificar el modelo, se 
supone que la secuencia de acciones al usar el microondas es: 

1 . Seleccionar el nivel de potencia (ya sea media o maxima) . 

2. Introducir el tiempo de coccion. 

3. Pulsar el boton de inicio, y la comida se cocina durante el tiempo establecido. 

Por razones de seguridad, el homo no deberia funcionar cuando la puerta este abierta y. 
cuando se completa la coccion, suena un timbre. El homo dispone de una pantalla alfanume- 
rica sencilla que se utiliza para visualizar varios mensajes de alerta y de precaucion. 
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Modelo de maquina 
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sencillo homo 
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La notacion UML utilizada para describir los modelos de maquina de estados esta disena- 
da para modelar el comportamiento de los objetos. Sin embargo, es una notacion de proposi- 
to general que se puede utilizarpara cualquier tipo de modelado de maquina de estados. Los 
rectangulos redondeados en un modelo representan los estados del sistema. Incluyen una bre- 
ve descripcion (a continuacion de «do») de las acciones realizadas en ese estado. Las flechas 
etiquetadas representan estimulos que fuerzan transiciones de un estado a otro. 

Por lo tanto, en la Figura 8.5, podemos ver que el sistema responde bien inicialmente al 
boton de potencia maxima o al de potencia media. Los usuarios pueden cambiar de idea des- 
pues de seleccionaruno de estos y presionar el otro boton. Se fijael tiempo y, si lapuerta esta 
cerrada, se habilita el boton de comienzo. Pulsando este boton comienza a funcionar el hor- 
no y la coccion tiene lugar durante el tiempo especificado. 

La notacion UML indica la actividad que tiene lugar en un estado. En una especificacion 
detallada del sistema, usted tiene que proporcionar mas detalle sobre el estimulo y los esta- 
dos del sistema (Figura 8.6). Esta informacion puede mantenerse en un diccionario de datos 
o enciclopedia (incluida en la Seccion 8.3) y que es mantenida por las herramientas CASE uti- 
lizadas para crear el modelo del sistema. 

El problema con la aproximacion de la maquina de estados es que el numero de posibles 
estados crece rapidamente. Por lo tanto, para los modelos de sistemas grandes, es necesaria 
una cierta estructuracion de estos modelos de estados. Una forma de hacer esto es mediante 
la nocion de un superestado que encierra a varios estados separados. Este superestado se ase- 
meja a un unico estado de un modelo de alto nivel, pero se expande a continuacion con mas 
detalle en un diagrama distinto. Para ilustrar este concepto, considere el estado Funciona- 
miento en la Figura 8.5. Este es un superestado que puede expandirse, tal y como se ilustra 
en la Figura 8.7. 
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Enespera 


El homo esta esperando la entrada. la pantatla muestra la hora actual. 


Potencia media 


La potencia del homo se fija en 300 vatios. La pantalla muestra (Potencia 
media*. 


Potencia maxima 


La potencia del homo se fija en 600 vatios. La pantalla muestra ■Potencia 
maxima*. 


Fijar tiempo 


Se fija el tiempo de coccion con el valor de entrada del usuario. La panta- 
lla muestra el tiempo de coccion seleccionado y se actualize en cuartto se 
n|a ei tiempo. 


Inhabilitado 


>e innaDiina ei TuncionanrienEO uei nomo por razones uc segunoao- ui im 
interior del homo se enciende. La pantalla muestra «No Ksto». 


Habilitado 


Se habilita el funcionamiento del homo. Se apaga la luz de su interior. La 
pantalla muestra «Listo para codnar*. 


Funriorvamiento 


El homo esta en funcionamiento. La luz interior del homo se enciende. La 
pantalla muestra ta cuenta atras de) temporizador. Cuando final iza la coc- 
cion, suena un timbre durante 5 segundos. La Krz interior se enciende. La 
pantalla muestra (Coccion finalizada» mientras el timbre suena. 


Estimulo 


Descripcion 


Potencia media 


El usuario ha presionado ef bot6n de potencia media. 


Potencia maxima 


El usuario ha presionado el baton de potencia maxima. 


Temporizador 


El usuario ha presionado uno de los botones del temporizador. 


Niimero 


El usuario ha presionado una teda numenca. 



Puefta abierta El 'mterruptor de la puerta del homo no esta cerrado. 



Puerta cerrada Ei interruptor de la puerta del homo esta cerrado. 

Iniciar El usuario ha presionado el boton de initio. 

Cancelar El usuario ha presionado el boton de cancdar. 



El estado Funcionamiento incluye varios subestados. Muestra que una operacion co- 
mienza con una comprobacion de estado, y que si se descubre cualquier problema, se activa 
una alarma y la operacion queda inhabilitada. La coccion implica poner en marcha el gene- 
rador de microondas durante el tiempo especificado; a su terminacion, suena un timbre. Si la 
puerta se abre durante el funcionamiento, el sistema se mueve al estado inhabilitado, ta! y 
como se muestra en la Figura 8.5. 



8.3 Modelos de datos 

La mayoria de los sistemas software grandes utilizan bases de datos de informacion de gran 
tamafio. En algunos casos, esta base de datos es independiente del sistema software. En otros, 
se crea para el sistema que se esta desarrollando. Una parte importante del modelado de sis- 
temas es la definicion de la forma logica de los datos procesados por el sistema. Estos se de- 
nominan a menudo modelos semdnticos de datos. 

La tecnica de modelado de datos mas ampliamente usada es el modelado Entidad-Rela- 
cion-Atributo (modelado E R A ) , que muestra las entidades de datos, sus atributos asociados y 
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Flgura 8.8 
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de autor 
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editor 
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Al igual que todos los modelos graficos, a los modelos de datos les faltan detalles, y usted 
deberia mantener descripciones mas detalladas de las entidades, relaciones y atributos in- 
cluidas en el modelo. Usted puede reunir estas descripciones mas detalladas en un reposito- 
rio o diccionario de datos. Los diccionarios de datos generalmente son utiles cuando des- 
arrollamos modelos de sistemas y pueden utilizarse para gestionar toda la informacion de 
todos los tipos de modelos de sistemas. 

Un diccionario de datos es, de forma simple, una lista de nombres ordenada alfabetica- 
mente incluida en los modelos del sistema. El diccionario deberia incluir, ademas del nom- 
bre, una descripcion asociada de dicha entidad con nombre y, si el nombre representa un ob- 
jetocompuesto,unadescripcionde lacomposicion. Se puede incluir otra informacion, como 
la fecha de creacion, el creadory larepresentacionde la entidad dependiendo del tipo de mo- 
delo que se este desarrollando. 

Las ventajas de usarun diccionario de datos son las siguientes: 

1. Es un mecanismo para la gestion de nombres. Muchas personas pueden tener que in- 
ventar nombres para las entidades y relaciones cuando estan desarrollando un mode- 
lo de un sistema grande. Estos nombres deberian ser usados de forma consistente y no 
deberian entrar en conflicto. El software del diccionario de datos puede comprobar la 
unicidad de los nombres cuando sea necesario y avisar a los analistas de requerimien- 
tos de las duplicaciones de nombres. 

2. Sirve como un almacen de informacion de la organization. A medida que el sistema 
se desarrolla, la informacion que enlaza el analisis, disefio, implementacion y evolu- 
cion se aflade al diccionario de datos, para que toda la informacion sobre una entidad 
este en un mismo lugar. 

Las entradas del diccionario de datos mostradas en la Figura 8.9 definen los nombres en el 
modelo semantico de datos para LI B SYS (Figura 8.8). Se ha simplificado lapresentacion de 
este ejemplo obviando algunos nombres y reduciendo la informacion asociada. 
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Artfcub Detalle del artfcuk) pubticado que Entidad 30.12.2002 

puede pedirse por las personas 
que us«n UBSYS 



Figura 8.9 
Ejemplos de 
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Autores 




Los nombres de los autores del artfcuk) 
que pueden compartir k» honorarios 


Atributo 


30.12.2002 


Comprador 




La persona u organ izatidn que emite 
una orden de oopia del artfcuk) 


Entidad 


30.12.2002 


Honorarios a paj 


jar a 


Una relation 1 :1 entre Artfculo y la 
Agenda de derechos de autor a quien 
se deberfa abonar el honorario 
de derechos de autor 


Relatidn 


29.1X2002 


Direction (Comprador) 


La direction del comprador. Esta se 
utHiza para cualquier information que 
se requiem sob re la factura en pa pel 


Aiributo 


31.12.2002 



Todos los nombres del sistema, tanto si son nombres de entidades, relaciones, atributos o ser- 
vicios, deberian introducirse en el diccionario. El software se utiliza normalmente para crear, 
mantener y consultar el diccionario. Este software deberia integrarse con otras herramientas 
para que la creacion del diccionario se automatice parcialmente. Por ejemplo, las herramientas 
CASE que soportan el modelado del sistema incluyen soporte para el diccionario de datos e in- 
troducen los nombres en el diccionario cuando se utilizan porprimera vez en el modelo. 



8.4 Modelos de objetos 

Una aproximacion orientada a objetos para el proceso de desarrollo del software en su totali- 
dad se usa actualmente de forma generalizada, en particular para el desarrollo de sistemas 
interactivos. Esto significa expresar los requerimientos de los sistemas utilizando un modelo 
de objetos, disenar utilizando objetos y desarrollar el sistema en un lenguaje de programacion 
orientado a objetos, como por ejemplo Java o C++. 

Los modelos de objetos que usted desarrolla durante el analisis de requerimientos pueden 
utilizarse para representar tanto los datos del sistema como su procesamiento. A este respec- 
to, dichos modelos combinan algunos de los usos de los modelos de flujo de datos y los mo- 
delos semanticos de datos. Los modelos de objetos tambien son utiles para mostrar como se 
clasifican las entidades en el sistema y se componen de otras entidades. 

Para algunas clases del sistema, los modelos de objetos son formas naturales de reflejar las 
entidades del mundo real que son manipuladas por el sistema. Esto es particularmente cierto 
cuando el sistema procesa informacion sobre entidades tangibles, tales como coches, aviones 
o libros, que tienen atributos claramente identificables. Entidades mas abstractas, y de mas 
alto nivel, tales como el conceptode unabiblioteca, un sistema deregistros medico soun pro- 
cesadorde texto, son mas dificiles de modelarcomo clases de objetos. Estos no tienen nece- 
sariamente una interfaz sencilla consistente en atributos independientes y operaciones. 

El desarrollo de modelos de objetos durante el analisis de requerimientos normalmente 
simplifica latransicion entre el diseno orientado a objetos y la programacion. Sin embargo, 
se observa que los usuarios de un sistema a menudo buscan modelos de objetos no naturales 
y dificiles de entender. Ellos pueden preferir adoptar un punto de vista mas funcional y de pro- 
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ceso de datos. Por lo tanto, a veces es util complementar el modelo de objetos con modelos 
de flujos de datos que muestren el procesamiento de datos en el sistema desde el principio has- 
ta el final. 

Una clase de objetos es una abstraccion sobre un conjunto de objetos que identifica atri- 
butos comunes (como en un modelo semantico de datos) y los servicios u operaciones que son 
proporcionados por cada objeto. Los objetos son entidades ejecutables que tienen atributos y 
servicios de la clase de objetos. Los objetos son instanciaciones de la clase de objetos, y pue- 
den crearse muchos objetos a partir de una clase. Generalmente, los modelos desarrollados 
utilizando analisis se centran en las clases de objetos y en sus relaciones. 

En el analisis de requerimientos orientado a objetos, deberian modelarse entidades del 
mundo real utilizando clases de objetos. No deberian incluirse detalles de los objetos indivi- 
duals (instanciaciones de la clase) en el sistema. Se pueden crear diferentes tipos de mode- 
los de objetos, mostrando como las clases de objeto se relacionan unas con otras, como los 
objetos son agregados para formar otros objetos, como los objetos interactuan con otros ob- 
jetos, etcetera. Cada uno de estos presenta una informacion distinta sobre el sistema que se 
esta especificando. 

El proceso de analisis para identificar los objetos y las clases de objetos se reconoce como 
una de las areas mas dificiles del desarrollo orientado a objetos. La identificacion de objetos 
es basicamente la misma para el analisis y para el diseno. Pueden utilizarse los metodos de 
identificacion de objetos tratados en el Capitulo 14, que analiza el diseno orientado a objetos. 
Aqui se tratan algunos de los modelos de objetos que podrian generarse durante el proceso de 
analisis. 

En los anos 90 se propusieron varios metodos de analisis orientados a objetos (Coad y 
Yourdon, 1990; Rumbaugh et a'u, 1991 ; Jacobsen eral., 1993; Booch, 1994). Estos metodos 
tienen mucho en comun, y tres de estos desarrolladores (Booch, Rumbaugh y Jacobsen) de- 
cidieron integrar sus aproximaciones para producir un metodo unificado (Rumbaugh et a/., 
1999b). El Lenguaje Unificado de Modelado (UML) utilizado en este metodo unificado se ha 
convertido en un estandarpara el modelado de objetos. UML incluye notaciones para dife- 
rentes tipos de modelos de sistemas. Nosotros ya hemos visto los modelos de casos de uso y 
los diagramas de secuencia en capitulos anteriores y los modelos de maquinas de estados al 
principio de este capitulo. 

Una clase de objetos en U M L , como se ha ilustrado en los ejemplos de la Figura 8.10, se 
representa como un rectangulo orientado verticalmente con tres secciones: 

1. El nombre de la clase de objetos esta en la seccion superior. 

2. Los atributos de la clase estan en la seccion intermedia. 

3. Las operaciones asociadas con la clase de objetos estan en la seccion inferior del rec- 
tangulo. 

debido a la limitacion de espacio para incluir todo sobre UML, aqui solo se tratan mode- 
los de objetos que muestran como los objetos pueden clasificarse y pueden heredar atributos 
y operaciones de otros objetos, modelos de agregacion que muestran como estan compuestos 
los objetos, y modelos de comportamiento sencillos, que muestran las interacciones entre los 
objetos. 

8.4.1 Modelos de herencla 

El modelado orientado a objetos implica la identificacion de clases de objetos que son im- 
portantes en el dominio que se esta estudiando. Estos objetos se organizan a continuacion 
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en una taxonomia. Una taxonomia es un esquema de clasificacion que muestra como una 
clase de objetos esta relacionada con otras clases a traves de atributos y servicios comu- 
nes. 

Para mostrar esta taxonomia, las clases se organizan en unajerarquiade herenciacon las 
clases de objetos mas generates al principio de lajerarquia. Los objetos mas especializados 
heredan sus atributos y servicios. Estos objetos especializados pueden tener sus propios atri- 
butos y servicios. 

La Figura 8.10 ilustra parte de unajerarquiade clases simplificadaparaunmodelo de bi- 
blioteca. Estajerarquiaproporcionainformacion sobre los elementos almacenadosenlabi- 
blioteca. La biblioteca comprende varios elementos, tales como libros, musica, grabaciones 
de peliculas, revistas y periodicos. En La Figura 8. LO, el elemento mas general esta en la raiz 
del arbol y tiene un conjunto de atributos y servicios que son comunes a todos tos elementos 
de la biblioteca. Estos son heredados por las clases Elemento publicado y Elemento regis- 
trado, que anaden sus propios atributos que son heredados a continuacion por elementos de 
niveles inferiores. 

La Figura 8.11 es un ejemplo de otrajerarquiade herenciaque podria ser parte del mode- 
lo de biblioteca. En este caso, se muestran los usuarios de una biblioteca. Hay dos clases de 
usuarios: aquellos a los que se les permite pedir prestados libros, y aquellos que solo pueden 
leer los libros en la biblioteca sin llevarselos. 

En la notacion UML, ta herencia se muestra «hacia arriba» en lugar de «hacia abajo» 
como en otras notaciones orientadas a objetos o en lenguajes tales como Java, en donde 
las subclases heredan de las superclases. Es decir, la punta de la flecha (mostrada como 
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un triangulo) apunta desde las clases que heredan sus atributos y operaciones hasta su su- 
perclase. En lugar de utilizar el termino herencia, U M L habla de relation de generaliza- 
tion. 

El diseno de jerarquias de clases no es facil, ya que el analista necesita comprender con 
detalle el dominio en el que el sistema sera implantado. Como ejemplo de los problemas su- 
tilesque surgen en lapractica, considere lajerarquiade elementosde labiblioteca. Podriapa- 
recerque el atributo Titulo podria situarse como el elemento mas general, y a continuacion 
ser heredado por elementos de niveles inferiores. 

Sin embargo, si bien cada elemento en una biblioteca debe tener algun tipo de identifica- 
doro numero de registro, esto no significa que todos los elementos deban tener un titulo. Por 
ejemplo, una biblioteca puede almacenar ciertos elementos personales de un politico retira- 
do. Muchos de estos elementos, tales como cartas, pueden no tener un titulo de forma expli- 
cita. Estos seran clasificados utilizando alguna otra clase (no mostrada aqui) que tiene un con- 
junto diferente de atributos. 

Las Figuras 8.10 y 8.11 muestran jerarquias de herencia de clases en las que cada clase 
de objetos hereda sus atributos y operaciones de una unica clase padre. Tambien pueden 
construirse modelos de herencia en los que una clase tiene varios padres. Sus atributos y ser- 
vicios son una conjuncion de los heredados de cada superclase. La Figura 8.12 muestra un 
ejemplo de modelo de herencia multiple que tambien puede ser parte del modelo de bi- 
blioteca. 

El problema principal con la herencia multiple es el diseno deun grafo de herencia en don- 
de los objetos no heredan atributos innecesarios. Entre otros problemas se incluye ladificul- 
tad de reorganizar el grafo de herencia cuando se requieren cambios y resolver conflictos de 
nombres cuando dos o mas superclases tienen el mismo nombre pero diferentes significados. 
A nivel de modelado de sistemas, tales conflictos son relativamente faciles de resolver alte- 
rando manualmente el modelo de objetos. Esto puede ocasionarmas problemas en la progra- 
macion orientada a objetos. 
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8.4.2 Agregaclon de objetos 

Asi como se adquieren atributos y servicios a traves de una relacion de herencia con otros 
objetos, algunos objetos son agrupaciones de otros objetos. Es decir, un objeto es un agre- 
gado de un conjunto de otros objetos. Las clases que representan a estos objetos pueden 
modelarse utilizando un modelo de agregacion, tal y como se muestra en la Figura 8.13. 
En este ejemplo, se ha modelado un elemento de biblioteca, consistente en un paquete de 
estudio para un curso universitario. El paquete de estudio comprende apuntes de clase, 
ejercicios, soluciones ejemplo, copias de las transparencias usadas en las clases y cintas 
de video. 

La notacion U M L para la agregacion consiste en representar la composicion incluyendo 
una figura de diamante colocada sobre el elemento fuente del enlace. Por lo tanto, la Figu- 
ra 8.13 puede leerse como «Un paquete de estudio esta compuesto por uno o varios ele- 
mentos asignados, paquetes de transparencias OHP, apuntes y cintas de video». 
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8.4.3 Modelado de comportamlento de objetos 

Para modelar el comportamiento de los objetos, se tiene que mostrarcomo se utilizan las ope- 
raciones proporcionadas por los objetos. En U M L , se modelan los comportamientos utilizan- 
do escenarios que son representados como casos de uso UML (estudiados en el Capitulo 7). 
Una forma de modelar los comportamientos es utilizar diagramas de secuencia UML que 
muestran la secuencia de acciones implicadas en un caso de uso. Ademas de los diagramas 
de secuencia, UML tambien incluye diagramas de colaboracion que muestran la secuencia de 
mensajes intercambiados por los objetos. Estos diagramas son similares a los diagramas de 
secuencia, por lo que no se tratan aqui. 

Se puede ver como se pueden utilizar los diagramas de secuencia para modelar el com- 
portamiento en laFigura 8.14, que expande un caso de uso del sistemaLIB SYS en el que los 
usuarios solicitan prestamos a la biblioteca en formato electronico. Por ejemplo, imagine una 
situacion en la que los paquetes de estudio mostrados en la Figura 8.13 podrian mantenerse 
en formato electronico y descargarse a la computadora del estudiante. 

En un diagrama de secuencia, los objetos y los actores se alinean en la parte superior del 
diagrama. Las flechas etiquetadas indican las operaciones; la secuencia de operaciones se lle- 
va a cabo desde arriba hacia abajo. En este escenario, el usuario de la biblioteca accede al ca- 
talogo para ver si el elemento solicitado estadisponible en formato electronico; si lo esta, el 
usuario solicita dicho elemento. Por razones de derechos de autor, se debe asignar una licen- 
cia al elemento para que exista una transaccion entre el elemento y el usuario, que debe acep- 
tar dicha licencia. El elemento solicitado se envia a un objeto servidor de red para su com- 
presion antes de ser enviado al usuario de la biblioteca. 

Se puede encontrar otro ejemplo de un diagrama de secuencia que expande un caso de uso 
de LIB SYS en la Figura 7.8, que muestra la secuencia de actividades implicadas en la im- 
presion de un articulo. 
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8.5 Me tod os estructurados 

Un metodo estructurado es una forma sistematica de elaborar modelos de un sistema existente 
o de un sistema que tiene que ser construido. Fueron desarrollados por primera vez en la de- 
cadade los 70 para soportar el analisis y el diseno del software (Constantine y Yourdon, 1979; 
Gane y Sarson, 1 979; Jackson, 1983) y evolucionaron en las decadas de los 80 y de los 90 para 
soportar el desarrollo orientado a objetos (Rumbaugh etal., 1991; Robinson, 1992; Jacobsen, 
etal., 1993; Booch, 1994). Estos metodos orientados a objetos se unieron con la propuesta 
U M L como lenguaje de modelado estandar (Booch ex al., 1 999; Rumbaugh et al., 1 999a) y 
el Proceso Unificado (Rumbaugh etal., 1 999b), y mas tarde con el Proceso Unificado de Ra- 
tional (Krutchen, 2000) como un metodo asociado estructurado. Budgen (Budgen, 2003) re- 
sume y compara varios de estos metodos estructurados. 

Los metodos estructurados proporcionan un marco para el modelado detallado de sistemas 
como parte de la elicitacion y analisis de requerimientos. La mayoria de metodos estructura- 
dos tienen su propio conjunto preferido de modelos de sistemas. Normalmente definen un pro- 
ceso que puede utilizarse para derivar estos modelos y un conjunto de reglas y guias que apli- 
can a dichos modelos. Se genera una documentacion estandarpara el sistema. Normalmente 
se encuentran disponibles herramientas CASE que soportan el uso de metodos. Estas herra- 
mientas soportan la edicionde modelos ygeneracionde codigoy documentacion, y propor- 
cionan algunas capacidades para comprobar los modelos. 

Los metodos estructurados han sido aplicados con exito en muchos proyectos grandes. 
Pueden suponer reducciones significativas de coste debido a que utilizan notaciones estandar 
y aseguran que se produce una documentacion de diseno estandar. Sin embargo, los metodos 
estructurados tienen una serie de inconvenientes: 

1 . No proporcionan un soporte efectivo para la comprension o el modelado de requeri- 
mientos del sistema no funcionales. 

2. No discriminan en tanto que normalmente no incluyen guias que ayuden a los usua- 
rios a decidir si un metodo es adecuado para un problema concreto. Tampoco inclu- 
yen normalmente consejos sobre como pueden adaptarse para su uso en un entorno 
particular. 

3. A menudo generan demasiada documentacion. La esencia de los requerimientos del 
sistema puede quedaroculta por e) volumen de detalle que se incluye. 

4. Los modelos producidos son muy detallados, y los usuarios a menudo los encuentran 
dificiles de entender. Estos usuarios, por lo tanto, no pueden comprobar el realismo de 
estos modelos. 

En la practica, sin embargo, los ingenieros de requerimientos y los disenadores no se res- 
tringen a los modelos propuestos por un metodo determinado. Por ejemplo, los metodos 
orientados a objetos no sugieren normalmente que los modelos de flujos de datos deban desa- 
rrollarse. Sin embargo, segun mi experiencia, dichos modelos son a menudo utiles como par- 
te del proceso de analisis de requerimientos debido a que pueden presentar un panorama ge- 
neral del procesamiento en el sistema desde el principio hasta el final. Tambien pueden 
contribuir directamente a la identificacion de los objetos (los datos que fluyen) y la identifi- 
cacion de las operaciones sobre esos objetos (las transformaciones). 

Las herramientas CASE de analisis y diseno soportan la creacion, edicion y analisis de las 
notaciones graficas utilizadas en los metodos estructurados. La Figura 8.15 muestra los com- 
ponentes que pueden ser incluidos en los entornos que soportan metodos. 
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Figure 8.15 Los 

componentes de 
una herramienta 
CASE para el soporte 
de metodos 
estructurados. 




Las herramientas que soportan metodos completos, tal y como se ilustra en la Figura 8.15, 
normalmente incluyen: 

1 . Editores de diagramas utilizados para crear modelos de objetos, modelos de datos, 
modelos de comportamiento, etcetera. Estos editores no son simplemente herramien- 
tas de dibujo puesto que identifican los tipos de entidades en el diagrama. Captan la 
informacion sobre estas entidades y guardan esta informacion en el repositorio cen- 
tral. 

2. Herramientas de andlisis y comprobacion de disehos que procesan el diseno e infor- 
man sobre errores y anomalias. Pueden integrarse con el sistema de edicion para que 
los errores del usuario sean detectados en etapas tempranas del proceso de desarrollo. 

3. Lenguajes de consulta del repositorio que permite al disefiador encontrardisefios e in- 
formacion asociada a los disenos en el repositorio. 

4. Un diccionario de datos que mantiene informacion sobre las entidades utilizadas en 
el diseno de un sistema. 

5. Herramientas de generation y definition de informes que obtienen informacion del al- 
macen central y generan automaticamente la documentacion del sistema. 

6. Herramientas de definition de formularios que permiten especificar los formatos de 
pantallas y de documentos. 

7. Facilidades para importar/exportar que permiten el intercambio de informacion des- 
de el repositorio central con otras herramientas de desarrollo. 

8. Generadores de codigo que generan codigo o esqueletos de codigo de forma automa- 
tica a partirdel diseno capturado en el almacen central. 

La mayoria de los conjuntos de herramientas CASE completos permiten al usuario ge- 
nerar un programa o un fragmento de un programa a partir de la informacion proporciona- 
da en el modelo del sistema. Las herramientas CASE a menudo soportan diferentes len- 
guajes para que el usuario pueda generar un programa en C, C++ o Java a partir del mismo 
modelo de diseno. Debido a que los modelos excluyen detalles de bajo nivel, el generador 
de codigo en un banco de trabajo de diseno no puede normalmente generar el sistema com- 
plete Normalmente es necesaria alguna codificacion manual para anadir detalles al codi- 
go generado. 
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PUNTOS CLAVE 

• Un modeto es una ^sta abstracta de un sfetema que prescfcide cte ajgjios detales del mfema Rieden des- 
anotase modelos dd sistema oornplementarios para presenter aba Informaclon sabre dfcho sistema 

• Los iwo d alos de cori ta to muesben como el sistema que se esta modebndo se uMca en in entemo con abas 
sfetemas y procesos. Daman los tarites dX sistema. lis modetos arqultectonlcos. los mo d elos de procesos 
y mo d elos de flu]os de dates puBtfan uWhmsb oomo modelos de ooritodo. 

• los dfagamas de flujo de dates pueden uMzarss para modefar el pwcesaifato de los dates farado a abo 
par ui sistema B sistema se modeia oomo un conjunto de fcansfonnadones de dates con fcndones que ao- 
tuan soure tos dates 

• Los modelos de maqulna de estados se uUfcan para modalar el ocn^ntarrfento del sistema en lespuesta a 

• Los modelos semantlcos de daljo describen b esnucnia loglca de los dates lijjortados y eyottados par el 
sfetema Estos modelos mueshan las enMdades del sfetema sus abtoutos y tas retedones en tas que titer- 
vtenen. 

• Los modelos de objetes desolieii las c rt Ma d e s Idglcas del sistema y su clasfflcaclon y agregaclon. Oombt- 
nBn ui mocteb cte cfatas con ui moffeb cte proo6S3nfferitaL Posfctes itidcIbIos cte ofafstas qub puBcten c te s n * 
nolarae hduyen modelos de herencta, modelos de agregaclon y modelos de conyortamterito. 

• Los modelos de secuencla que rnuasfcan las hteraod ones ertbe a cte ra s y objetes en un sbtema se uBfcan 
para modebr el oarnportamTartto dmarmco. 

• los metodos esnuchiados propotltarian ut maoo para soportar d 

metodos esbuduados nomatnlVb son soporiados de fama e w tens V a par henntentas CASE, hdu/sndo 
b edlclon de modelos y b comprobaclon y generation de codlgo. 



LECTURAS ADICIONALES 



Software Design, 2nd ed. Si bien este libro se centra fundamentalmente en el diseno del software, el autor analiza 
varios metodos estructurados que tambien pueden utilizarse en el proceso de ingenieria de requerimientos. No se 
centra solamente en aproximaciones orientadas a objetos. (D. Budgen, 2003, Addison-Wesley.) 

Requirements Analysis and System Design. Este libro se centra en el analisisde sistemas de inf ormacion y 
explica como pueden utilizarse d if e rentes modelos UMLen el proceso tie anal isis. (L. Maciaszek, 2001, Addison- 
Wesley.) 

Software Engineering with Objects and Components. Una breve introduccion facll de leer para el uso de UML en la 
especif icacion y diseno del sistema. Aunque no contiene una completa descripcion de la notacidn UML, este libro 
indudablemente es el mejor si usted esta intentando aprender y comprender dicha notacidn. (P. Stevens with R. 
Pooley, 1999, Addison-Wesley.) 
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EJERCICIOS M HUk . wmwmmmmmmmmmmmmmm 



8.1 Dibuje un modelode contexto para un si stem a de informacidnde pacientes en un hospital, listed puede ha- 
cer cualquier suposicion razonable sobre otros sistemas existentes en el hospital, pero su modelo debe In- 
cluir un sistema deadmisidnde pacientes y un sistema dealmacenamientodeimagenesde rayosX asicomo 
otros almacenamientos dediagndsticos. 

&2 Basandose en su experiencia con los cajeros automaticos, dibuje un diagrama de flujo de datos para mo- 
delar el procesamiento de los datos que se debe realizar cuando un cliente solicita efectivo en un cajero. 

83 Modele el procesamiento de los datos que podria tener lugaren un sistema de correo electronico. Listed de- 
ben a modelar et proceso de envio de correos yde recepcidn de correos de forma separada. 

&4 Dibuje una maquina de estados que modele el software de control para: 

• Una lavadora automation que tenga diferentes programas para distintos tipos de ropa. 

• El software para un reproductor de DVD. 

• Un sistema de contestador telefdnico que almacene mensajes entrantes y visualice el numero de men- 
sajes aceptados en un LED. El sistema deberia permitir a I propietario deltelefono realizar llamadasdes- 
de cualquier lugaral contestador, teclear una secuencia de numeros (identificados por tonos) y reproducir 
los mensajes almacenados. 

8.5 Un modelo de sistema de software puede representarse como un grafo dirigido en el que los nodos son Las 
entidades en el modelo y los arcos son las relaciones entre esas entidades. Las entidades y las relaciones 
en el modelo pueden ser etiquetadas con un nombre y otra informacidn. Cada entidad en el modelo tiene 
un tipo asociado y puede «expandirse» en un submodelo. Dibuje un modelo de datos que describa la es- 
tructura de un modelo de sistema de software. 

8.6 Modele las clases de objetosque podrian utilizarse en un sistema de correo electronico. Si ha intentado re- 
alizar el Ejercicio 8.3, describa las similitudes y diferencias entre el modelo de procesamiento de datos y el 
modelo de objetos. 

8.7 Utilizando la informacidn sobre los datos del sistema mostrados en la Figura 8.8, dibuje un diagrama de se- 
cuencia que muestre una posible secuencia de acciones que tenga lugar cuando un nuevo articulo es cata- 
logado por el sistema LIBSYS. 

&8 Desarrolle un modelo de objetos, incluyendo un diagrama de jerarquia de clases y un diagrama de agrega- 
cidn que muestre los principales componentes de un sistema de computadora personal y su software de sis- 
tema. 

8.9 Desarrolle un diagrama de secuencia que muestre las interacciones implicadas cuando un estudiante se re- 
gistra para un curso en una universidad. Los cursos pueden tener limitadas las plazas, de forma que el pro- 
ceso de registro debe incluir la comprobacidn de que hay plazas disponibles. Suponga que los estudiantes 
acceden auncatalogo elect rdnicode cursos para encontrar cursos disponibles. 

8.10 &En que circunstancias no recomendaria el uso de metodos estructurados para el desarrollo de sistemas? 
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Especificacion 

de sistemas criticos 



Objetivos 

El objetivo de este capitulo es explicarcomo especificar 
requerimientos de confiabilidad funcionales y no funcionales para 
sistemas criticos. Cuando haya leido este capitulo : 

• comprendera como los requerimientos de confiabilidad para 
sistemas criticos pueden identificarse mediante el analisis de 
riesgos con los que se enfrentan dichos sistemas; 

• comprendera que los requerimientos de seguridad se 
obtienen a partir del analisis de riesgos del sistema en vez de 
mediante personal externo al sistema; 

• comprendera el proceso de obtencion de requerimientos de 
proteccion y como dichos requerimientos son utilizados para 
combatir diferentes tipos de amenazas al sistema; 

• comprendera las metricas para la especificacion de la 
habilidad y como estas metricas pueden usarse para 
especificar requerimientos de fiabilidad. 

Contenidos 

9.1 Especificacion dirigida por riesgos 

9.2 Especificacion de la seguridad 

9.3 Especificacion de la proteccion 

9.4 Especificacion de la fiabilidad del software 
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En septiembre de 1993, un avion aterrizo en el aeropuerto de Warsaw en Polonia durante una 
fuerte tormenta. Durante nueve segundos despues del aterrizaje, los frenos del sistema de fre- 
nado controlado por computadora no funcionaron. El avion sobrepaso el final de la pista de 
aterrizaje, choco contra un monticulo de tierra y se incendio. La subsiguiente investigacion 
demostro que el software del sistema de frenos funciono perfectamente de acuerdo con su es- 
pecificacion. Pero, por razones en las que no precede entrar aqui, el sistema de frenos no re- 
conocio que el avion habia aterrizado. Una caracteristica de seguridad del avion detuvo el des- 
pliegue del sistema de frenado, ya que esto puede ser peligroso si el avion esta en el aire. El 
fallo de funcionamiento del sistema se debio a un error en la especificacion del sistema. 

Esto ilustra la importancia de la especificacion de sistemas criticos. Debido a los altos cos- 
tes potenciales de un fallo de funcionamiento del sistema, es importante asegurar que la espe- 
cificacion de los sistemas criticos refleja con exactitud las necesidades reales de los usuarios 
del sistema. SI no se consigue la especificacion correcta, entonces, independientemente de la 
calidad del desarrollo del software, el sistema no sera confiable. 

La necesidad de confiabilidad en los sistemas criticos genera requerimientos funcionales 
y no funcionales del sistema: 

1 . Los requerimientos funcionales del sistema se generan para definir la comprobacion 
de errores y facilidades de recuperacion y caracteristicas que proporcionan proteccion 
frente a fallos de funcionamiento del sistema. 

2. Los requerimientos no funcionales se generan para definir la fiabilidad y disponibili- 
dad requeridas por el sistema. 

Ademas de estos requerimientos, las consideraciones sobre seguridad y proteccion pueden 
generar otro tipo de requerimiento que es dificil de clasificar como funcional o no funcional. 
Son requerimientos de alto nivel que quizas se describen mejorcomo requerimientos «no de- 
beria». En contraste con los requerimientos funcionales normales que definen lo que el siste- 
ma deb eriahacer, los requerimientos «no deberia» definen el comportamiento del sistema que 
no es aceptable. Ejemplos de requerimientos «no deberia» son los siguientes: 

• El sistema no deberia permitir a los usuarios modificar los permisos de acceso de cual- 
quier fichero que no hayan creados ellos mismos (proteccion). 

• El sistema no deberia permitir seleccionar el modo de propulsion inversa cuando el 
avion este en el aire (seguridad). 

• El sistema no deberia permitir la activacion simultanea de mas de tres senales de alarma 
(seguridad). 

Algunas veces estos requerimientos «no deberia» se descomponen en requerimientos fun- 
cionales de software mas especificos. De forma alternativa, las decisiones de implementacion 
pueden posponerse hasta que se disene el sistema. 

Los requerimientos de usuario para sistemas criticos siempre se especifican utilizando el 
lenguaje natural y modelos de sistemas. Sin embargo, como se indica en el Capitulo 10, la es- 
pecificacion formal y la verificacion asociada son probablemente las de mayor coste efectivo 
en el desarrollo de sistemas criticos (Hall, 1996; Hall y Chapman, 2002; Wordsworth, 1996). 
Las especificaciones formales no son solamente una base para la verificacion del diseflo y la 
implementacion. Son la forma mas precisa de especificar sistemas y, por lo tanto, reducen los 
malentendidos. Ademas, la construccion de una especificacion formal fuerza a un analisis de- 
tallado de los requerimientos, lo que es una forma efectiva de descubrir problemas en la espe- 
cificacion. En una especificacion en lenguaje natural, los errores pueden encubrirse por la im- 
precision del lenguaje. Este no es el caso si el sistema se especifica formalmente. 
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9.1 Especificacion dirigida por riesgos 

La especificacion de sistemas criticos no es una alternativa al proceso habitual de especifica- 
cion de requerimientos. En su lugar, complementa a este ultimo proceso haciendo hincapie en 
la confiabilidad del sistema. Su objetivo es comprender los riesgos con los que se enfrenta el 
sistema y generar requerimientos de confiabilidad para tratar dichos riesgos. La especifica- 
cion dirigida por riesgos es una aproximacion que ha sido ampliamente utilizada por los des- 
arrolladores de sistemas de seguridad criticos y sistemas de proteccion criticos. En sistemas 
de seguridad criticos, los riesgos son contingencias que pueden provocar accidentes; en sis- 
temas de proteccion criticos, los riesgos son vulnerabilidades que pueden conducir a un ata- 
que con exito al sistema. Sin embargo, una aproximacion dirigida por riesgos es aplicable a 
cualquier sistema en el que la confiabilidad sea un atributo critico. 

El proceso de especificacion dirigido por riesgos implica comprender los riesgos con los que 
se enfrenta el sistema, descubriendo sus causas fundamentales y generando los requerimientos 
para gestionar dichos riesgos. La Figura 9.1 muestra el proceso iterativo del analisis de riesgos: 

I. Identification de riesgos. Se identifican los riesgos potenciales que podrian surgir. Es- 
tos dependen del entorno en el que se va a utilizar el sistema. 

1. Analisis y clasificacion de riesgos. Los riesgos se consideran de forma independien- 
te. Aquellos que son potencialmente serios y no previsibles se seleccionan para un ana- 
lisis posterior. En esta etapa, algunos riesgos pueden eliminarse simplemente debido 
a que es muy improbable que surjan (por ejemplo, tormentas electricas y terremotos). 

3. Descomposicion de riesgos. Cada riesgo se analiza individualmente para descubrir las 
causas potenciales fundamentales de ese riesgo. Se pueden utilizar tecnicas tales como 
el analisis del arbol de defectos (comentado mas adelante en este capitulo). 

4. Valoracion de la reduction de riesgos. Se hacen propuestas sobre las formas en las que 
los riesgos identificados pueden reducirse o eliminarse. Estos generan entonces re- 
querimientos de confiabilidad del sistema que definen las defensas frente al riesgo y 
como el riesgo va a ser gestionado si ocurre. 

Para sistemas grandes, el analisis de riesgos se puede estructurar en fases. El analisis de 
riesgos multifase es necesario para sistemas grandes tales como plantas quimicas o aviones. 
Las fases del analisis de riesgos comprenden: 

• Analisis preliminarde riesgos en el que se identifican los riesgos principales. 

• Analisis mas detallado de riesgos del sistema y subsistemas. 

• Analisis de riesgos del software en el que se consideran los riesgos de fallos de funcio- 
namiento del software. 

• Analisis de riesgos operacionales que comprenden la interfaz de usuario del sistema y 
los riesgos que surgen por los errores del operador. 
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Leveson (Leveson, 1995) trata el proceso multifase de analisis de riesgos en su libro sobre 
sistemas de seguridad criticos. 

9.1.1 Identificacion de riesgos 

El objetivo de la identificacion de riesgos, la primera etapa del proceso de analisis de riesgos, 
es identificar los riesgos con los que el sistema tiene que tratar. Esto puede ser un proceso di- 
ficil y complejo debido a que en ocasiones los riesgos aparecen como consecuencia de inter- 
acciones entre el sistema y condiciones inesperadas del entorno. El accidente de Warsaw que 
se ha comentado al principio ocurrio cuando los vientos de costado generados durante una tor- 
menta hicieron que el avion se inclinara de forma que aterrizo con una rueda en vez de con 
las dos. 

En sistemas de seguridad criticos, los riesgos principales son contingencias que provocan 
accidentes. Se puede abordar el problema de identificacion de contingencias considerando las 
diferentes clases de contingencias, tales como contingencias fisicas, electricas, biologicas, ra- 
diactivas, de fallo de servicio, etc. Cada una de estas clases puede analizarse para descubrir 
las contingencias asociadas. Tambiendeben identificarse las posibles combinaciones de con- 
tingencias. 

En el Capitulo 3 sepresentoun ejemplo de un sistema de unabomba de insulina. Al igual 
que muchos dispositivos medicos, estees un sistema de seguridad critico. Algunas de las con- 
tingencias o riesgos que podrian surgir en este sistema son: 

1 . Sobredosis de insulina (fallo de servicio) . 

2. Dosisbajade insulina (fallo de servicio). 

3. Fallo de energla debido a bateria agotada (electrico). 

4. Interferencia electrica con otros equipamientos medicos tal como un marcapasos (elec- 
trico). 

5. Contacto inadecuado entre el sensor y el actuador causado por una mala conexion (fi- 
sica). 

6. Las partes de la maquina sobre el cuerpo del paciente interrumpen su funcionamien- 

to (fisica). 

7. Infection provocada por la introduction de una maquina (biologica). 

8. Reaction alergica a los materiales o insulina usada en la maquina (biologica). 

Los riesgos relacionados con el software normalmente se asocian a fallos en la ejecucion 
de un servicio del sistema o con el fallo de sistemas de monitorizaciony protection. Los sis- 
temas de monitorizacion pueden detectar condiciones potenciales de contingencia tales como 
fallos en el suministro electrico. 

Los ingenieros con experiencia, que trabajan con expertos en el dominio y asesores de se- 
guridad profesionales, deberian identificar los riesgos del sistema. Las tecnicas de trabajo en 
grupo como la tormenta de ideas (brainstorming) se pueden usarpara identificar los riesgos. 
Los analistas con experiencia directa en incidentes previos tambien pueden ser capaces de 
identificar los riesgos. 

9.1.2 Analisis y claslflcaclon de riesgos 

El proceso de analisis y clasificacion de riesgos trata principalmente de comprender la pro- 
babilidad de que surja un riesgo y las consecuencias potenciales que tendrian lugar si se pro- 
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duce un accidente o incidente asociado a ese riesgo. Necesitamos realizar este analisis para 
comprender si un riesgo es una amenaza seria para el sistema o el entorno y proporcionar una 
base para decidir los recursos que se deberian usar para gestionar el riesgo. 

Para cada riesgo, el resultado del proceso de analisis y clasificacion de riesgos es una de- 
cision de aceptacion. Los riesgos pueden clasificarse de tres formas: 

1. Intolerable. El sistema debe diseflarse de tal forma que, o bien el riesgo no pueda ocu- 
rrir, o si ocurre, que no provoque un accidente. Los riesgos intolerables deberian ser, 
normalmente, aquellos que amenacen la vida humana o la estabilidad financiera de 
una empresa y que tienen una probabilidad de ocurrencia significativa. Un ejemplo 
de un riesgo intolerable para un sistema de comercio electronico en una libreria a tra- 
ves de Internet, por ejemplo, seria el riesgo de que el sistema cayese durante mas de 
un dia. 

2. Tan bajo como razonablementeprdctico (ALARP'). El sistema debe diseflarse para que 
la probabilidad de que ocurra un accidente debido a la contingencia correspondiente 
se minimice, sujeto a otras consideraciones tales como coste y entrega. Los riesgos cla- 
sificados como ALARP son aquellos que tienen menos consecuencias serias o con 
menos probabilidad de ocurrir. Un riesgo ALARP para un sistema de comercio elec- 
tronico podria ser la corrupcion de las imagenes de una pagina web que muestra el lo- 
gotipo de la empresa. Esto no es deseable comercialmente, pero es improbable que ten- 
ga consecuencias serias a corto plazo. 

3. Aceptable. SI bien los disefiadores del sistema deberian realizar todos losposibles pa- 
sos para reducir la probabilidad de ocurrencia de una contingencia «aceptable», dichos 
pasos no deberian incrementar los costes, tiempo de entrega u otros atributos no fun- 
cionales del sistema. Un ejemplo de un riesgo aceptable para un sistema de comercio 
electronico es el riesgo de que la gente use navegadores web con versiones beta que 
podrian no completar con exito los pedidos. 

La Figura 9.2 (Brazendale y Bell, 1994), desarrollada para sistemas de seguridad criticos, 
muestra estas tres regiones. La parte sombreada del diagrama refleja los costes para asegurar 
que los riesgos no provocan accidentes o incidentes. El cosle de disefio del sistema para tener 
en cuenta el riesgo es una funcion de la anchura del triangulo. Los costes mas altos se dan con 
los riesgos de la parte superior del diagrama; los mas bajos, con los riesgos de la cima del 
triangulo. 
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Los limites entre las regiones de la Figura 9.2 tienden a moverse a lo largo del tiempo, de- 
bido a expectativas publicas de seguridad y a consideraciones politicas. Si bien los costes fi- 
nancieros de aceptar los riesgos y de pagar cualquier accidente que pueda tener lugar pueden 
ser menores que los costes de prevencion de accidentes, la opinion publica puede demandar 
que dichos costes adicionales sean aceptados. Por ejemplo, puede ser mas barato para una em- 
presa tratar el problema de la polucion en las raras ocasiones en las que ocurra, que instalar 
sistemas para prevenir la polucion. Esto hubiera sido aceptable en los anos 60 y 70, pero pro- 
bablemente hoy en dia no es aceptable publica o politicamente. En este caso, el limite entre 
la region intolerable y la region A L A R P se ha movido hacia abajo para que los riesgos que 
hubieran sido aceptados en el pasado sean ahora intolerables. 

La valoracion del riesgo comprende la estimacion de la probabilidad y severidad del ries- 
go. Normalmente este es muy dificil de llevar a cabo de forma exacta y generalmente depen- 
de de valoraciones de ingenieria. Las probabilidades y severidades de los riesgos se asignan 
utilizando terminos relativos tales como probable, improbable, y raroy alto, medio y bajo. 
La experiencia previa en el sistema puede permitir asociar algun valor numerico a estos ter- 
minos. Sin embargo, debido a que los accidentes son relativamente poco comunes, es muy di- 
ficil validar la exactitud de este valor. 

La Figura 9.3 muestra una clasificacion de riesgos para los riesgos (contingencias) identi- 
ficados en la seccion previa para el sistema de suministro de insulina. Las estimaciones son 
simplemente ilustrativas. La figura no muestra necesariamente las probabilidades y severida- 
des reales que podrian tener lugar en un analisis real de un sistema de suministro de insulina. 
Se debe hacer notar que a corto plazo una sobredosis de insulina es potencial mente mas seria 
que una dosis baja de insulina. Una dosis baja de insulina puede provocar perdida de conoci- 
miento, estado de coma y en ultima instancia la muerte. 

Las contingencias 3-8 no estan relacionadas con el software; por lo tanto, no se hablara mas 
de ellas aqui. Para contabilizar estas contingencias, la maquina deberia tener software de au- 
toverificacion para monitorizar el estado del sistema y avisar de algunas de estas contingen- 
cias. A menudo la advertencia permitira detectar la contingencia antes de que provoque un ac- 
cidente. Ejemplos de contingencias que podrian detectarse son fallos de energia electrica y 
ubicacion incorrecta de la maquina. Por supuesto, la monitorizacion del software esta rela- 
cionada con la seguridad ya que un fallo en la deteccion de una contingencia podria provocar 
un accidente. 
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Figura 9.3 Analisis de riesgos de contingencias identificadas en una bomba de insulina. 
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9.1.3 Descomposicion de riesgos 

La descomposicion de riegos es el proceso de descubrir las causas fundamentales de los ries- 
gos de un sistema particular. Las tecnicas para la descomposicion de riesgos se han derivado 
principalmente del desarrollo de sistemas de seguridad criticos en los que el analisis de con- 
tingencias es una parte central del proceso de seguridad. El analisis de riesgos puede ser de- 
ductivo o inductivo. Las tecnicas deductivas o tecnicas descendentes, cuyo uso tiende a ser 
mas facil, comienzan con el riesgo y trabajan a partirde el hasta llegar al posible fallo de fun- 
cionamiento del sistema: las tecnicas inductivas o tecnicas ascendentes parten de una pro- 
puesta de fallo de funcionamiento del sistema e identifican que contingencias podrian ocurrir 
que diesen lugar a dicho fallo. 

Se han propuesto varias tecnicas como posibles aproximaciones a la descomposicion de 
riesgos. Estas incluyen revisiones y listas de comprobacion, asi como tecnicas mas formales 
como el analisis de redes de Petri (Peterson, 1981), logica formal (Jahanian y Mok, 1986) y 
analisis de arbol de defectos (Leveson y Stolzy, 1987; Storey, 1996). 

Aqui se trata el analisis del arbol de defectos. Esta tecnica fue desarrollada para sistemas 
de seguridad criticos y es relativamente facil de comprender sin un conocimiento especial del 
dominio. El analisis del arbol de defectos implica identificar eventos no deseados y trabajar 
hacia atras a partirde ese evento para descubrir las posibles causas de la contingencia. Se debe 
poner la contingencia como raiz del arbol e identificar los estados que pueden conducir a di- 
cha contingencia. A continuacion, para cada uno de esos estados, se identifican los estados 
que pueden conducir hasta el y se continua esta descomposicion hasta que se identifiquen las 
causas raiz del riesgo. Los estados se pueden unirmediante simbolos «and» y «or». Los ries- 
gos que requieren una combinacion de causas raiz normalmente son menos probables que los 
riesgos que pueden resultar de una unica causa raiz. 

La Figura 9.4 es el arbol de defectos para las contingencias relacionadas con el software 
del sistema de suministro de insulina. Las dosis bajas y las sobredosis de insulina realmente 
representan una sola contingencia, denominada «dosis incorrecta de insulina suministrada», 
a partir de la cual se puede dibujar un unico arbol de defectos. Por supuesto, cuando se espe- 
cificacomo deberia reaccionar el software ante las contingencias, se debe distinguirentre una 
dosis baja de insulina y una sobredosis de insulina. 

El arbol de defectos de la Figura 9.4 esta incompleto. Unicamente se han descompuesto 
por completo los defectos potenciales del software. No se muestran los defectos del hardware 
tales como un bajo nivel de bateria causante de un fallo en el sensor. En este nivel, no es po- 
sible hacerun analisis mas detallado. Sin embargo, si se incluye mas nivel de detalle en el di- 
seno y la implementacion, se pueden realizar arboles de defectos mas detallados. Leveson y 
Harvey (Leveson y Harvey, 1983) y Leveson (Leveson. 1985) muestran como los arboles de 
defectos pueden generarse durante el diseno del software descendiendo hasta el nivel de sen- 
tencias individuals del lenguaje de programacion. 

Los arboles de defectos se usan tambien para identificar problemas hardware potenciales. 
Un arbol de defectos puede proporcionar un mayor entendimiento de los requerimientos del 
software para detectar y, quizas, corregir estos problemas. Porejemplo, las dosis de insulina 
no se administran con una frecuencia muy alta, no mas de dos o tres veces por hora y algunas 
veces con menos frecuencia. Por ello, la capacidad del procesador esta disponible para eje- 
cutar programas de autocomprobacion y diagnosis. Los errores hardware tales como errores 
de sensores, de la bomba o del temporizador pueden descubrirse, ademas de mostrar los co- 
rrespondientes avisos, antes de que dichos errores tengan consecuencias serias sobre el pa- 
cicntc. 
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9.1.4 Valoraclon de la reduccldn de rlesgos 

Una vez que se han identificado los riesgos potenciales y sus causas, se deberian obtener los 
requerimientos de confiabilidad del sistema que gestionan los riesgos y aseguran que no ocu- 
rran incidentes ni accidentes. Hay tres posibles estrategias que pueden usarse: 

1. Evitacion de riesgos. El sistema se disefia para que el riesgo o la contingencia no pue- 
da ocurrir. 

2. Detection y elimination de riesgos. El sistema se disefia para que los riesgos se de- 
tecten y neutralicen antes de que provoquen un accidente. 

3. Limitation del daho. El sistema se disefia para que las consecuencias de un accidente 
se minimicen. 

Normalmente, los disefiadores de sistemas criticos utilizan una combinacion de estas apro- 
ximaciones. En un sistema de seguridad critico, las contingencias intolerables pueden mane- 
jarse minimizando suprobabilidad y afiadiendo un sistema de proteccion que proporcione co- 
pias de seguridad. Por ejemplo, en un sistema de control de una planta quimica, el sistema 
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intentara detectar y evitar el exceso de presion en el reactor. Sin embargo, tambien deberia ha- 
ber un sistema de proteccion independiente que monitorice la presion y abra una valvula de 
escape si se detecta una presion elevada. 

En el sistema de suministro de insulina, un «estado seguro» es un estado de apagado en el 
que no se suministra insulina. Durante un corto periodo esto no supondra una amenaza para 
la salud del diabetico. Si se consideran los problemas potenciales del software identificados 
en la Figura 9.4, se podrian dar las siguientes «soluciones»: 

1. Error aritmetico. Tiene lugar cuando alguncalculo aritmetico provocaun error dere- 
presentacion. La especificacion debe identificar todos los posibles errores aritmeticos 
que puedan ocurrir. Estos dependen del algoritmo utilizado. La especificacion debe- 
ria establecer que se incluya un manejador de excepciones para cada error aritmetico 
identificado. La especificacion deberia determinar la accion a realizar para cada uno 
de estos errores en caso de que aparezcan. Una accion segura es apagar el sistema de 
suministro y activar una alarma de advertencia. 

2. Error algoritmico. Esla es una situacion mas dificil ya que no es posible detectar una 
anomalia concreta. Podria detectarse comparando la dosis calculada de insulina re- 
querida con la dosis previamente suministrada. Si esta es mucho mayor, esto puede 
significar que lacantidad se ha calculado de forma incorrecta. El sistema tambien pue- 
de registrar las secuencias de dosis. Despues de un numero de dosis entregadas por en- 
cima de la media, se debe emitir una advertencia y limitar las nuevas dosis. 

Algunos de los requerimientos de seguridad resultantes para el sistema de suministro de 
insulina se muestran en la Figura 9.5. Estos son requerimientos del usuario y, naturalmente, 
deberian expresarse con mas detalle en una especificacion final del sistema. En estos reque- 
rimientos las referencias a las Tablas 3 y 4 hacen relacion a tablas que se deberian incluir en 
el documento de requerimientos. 

9.2 Especificacion de la seguridad 

El proceso de gestion de riesgos comentado hasta ahora ha evolucionado a partir de los pro- 
cesos desarrollados para sistemas de seguridad criticos. Hasta hace relativamente poco tiem- 
po, los sistemas de seguridad criticos eran mayormente sistemas de control en los que los fa- 
El sistema no debera* sumlnlstrar a un usuario del sktema una dosis de Insulina mayor 
que una dosis maxima especfflcada. 

□ sistema no debera sumlnlstrar a un usuario del sistema una dosis acumulada dlarla 
de Insulina mayor que una dosis maxima especfflcada 

□ sistema debera Incluir una facllldad para dlagndstlco de hardware que debera ejecu- 
tarse al menos cuatto veces por hora. 

El sistema debera* Incluir un manejador de excepciones para todas las excepciones Iden- 
tlflcadas en la Tabla 3. 

Una alarma audible deberia sonar cuando se descubra cualquler anomalia hardware o 
software y tambien deberia vlsuallzar un mensaje de dlagndstlco como el deflnldo en 
la Tabla 4. 

Cuando se genere un evento que provoque una alarma en el sistema, el sistema de In- 
sulina deberia suspenderse hasta que el usuario haya relnlciallzado el sistema y ellml- 
nado la alarma. 
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lios del equipamiento que se estaba controlando podian causar lesiones. En las decadas de los 
80 y 90, a medida que los sistemas de control se utilizan de forma mas extensa, la comunidad 
de ingenieros de seguridad desarrollo estandares para la especificacion y desarrollo de siste- 
mas de seguridad criticos. 

El proceso de especificacion y garantia de seguridad es parte de un ciclo de vida com- 
pleto de seguridad definido en un estandar internacional para la gestion de seguridad IEC 
61508 (IEC, 1998). Este estandar se desarrollo especificamenteparalaproteccionde sis- 
temas tales como un sistema de parada de un tren si este se salta una serial en rojo. Si bien 
el estandar mencionado puede usarse para sistemas de seguridad criticos mas generales, 
como sistemas de control, su separacion de una especificacion segura a partir de una es- 
pecificacion del sistema mas general parece inapropiada para sistemas de informacion cri- 
ticos. La Figura 9.6 ilustra el modelo de sistema que es asumido por el estandar IEC 
61508. 

La Figura 9.7 es una simplificacion de la presentacion de Redmill del ciclo de vida de se- 
guridad (Redmill, 1998). Como puede verse en la Figura 9.7, este estandar abarca todos los 
aspectos de la gestion de la seguridad desde el ambito inicial de la definicion pasando por la 
planificacion y desarrollo del sistema hasta la desmantel acion del mismo. 

En este modelo, el sistema de control controla dispositivos que tienen asociados unos re- 
querimientos de seguridad de nivel alto. Estos requerimientos de nivel alto generan dos tipos 
de requerimientos de seguridad mas detallados que se aplican a los dispositivos para la pro- 
teccion del sistema: 

1 . Requerimientos de seguridad funcionales que defmen las funciones de seguridad del 
sistema. 

2. Requerimientos de integridad seguros que definen la fiabilidad y disponibilidad de la 
proteccion del sistema. Dichos requerimientos estan basados en la forma esperadade 
uso del sistema de proteccion y pretenden asegurar que dicho sistema funcionara cuan- 
do sea necesario. Los sistemas se clasifican segun un nivel de integridad segura (SIL) 
desde 1 hasta 4. Cada nivel SIL representa un nivel mas alto de fiabilidad; cuanto mas 
critico sea el sistema, mas alto sera el SIL requerido. 

Las primeras etapas del ciclo de vida de seguridad IEC 61508 definen el ambito del siste- 
ma, evaluan las contingencias potenciales del sistema y estiman los riesgos que estas presen- 
tan. A continuacion tiene lugar la especificacion de requerimientos de seguridad y la asigna- 
cion de estos requerimientos de seguridad a los diferentes subsistemas. La actividad de 
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desarrollo comprende la planificacion y la implementacion. El sistema de segundad critico se 
disena e implementa. asi como los sistemas externos relacionados que puedan proporcionar 
proteccion adicional. En paralelo aesto, se planifica la validacion de la seguridad, instalacion, 
operacion y mantenimiento del sistema. 

La gestion de la seguridad no termina al entregar el sistema. Despues de la entrega, el 
sistema debe instalarse segun lo planificado, de tal forma que el analisis de contingen- 
cias siga siendo valido. Despues se lleva a cabo la validacion de seguridad antes de que 
el sistema comience a utilizarse. La seguridad debe ser tambien gestionada durante el 
tiempo de funcionamiento del sistema y (particularmente) durante el mantenimiento del 
sistema. Muchos de los problemas relacionados con los sistemas de seguridad criticos tie- 
nen lugar debido a un proceso de mantenimiento pobre, por lo que es particularmente im- 
portante que el sistema se disene pensando en su mantenibilidad. Finalmente, tambien de- 
berian tenerse en cuenta consideraciones de seguridad que podrian aplicarse durante el 
desmantelamiento del sistema (por ejemplo, desecho de material peligroso en tarjetas 
electronicas). 
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93 Especificacion de la proteccion 

La especificacion de los requerimientos de proteccion para los sistemas tiene algo en comun 
con los requerimientos de seguridad. No es practico especificarlos cuantitativamente, y los re- 
querimientos de proteccion son a menudo requerimientos «no deberia» que definen compor- 
tamientos inaceptables del sistemaen lugarde funcionalidades requeridas del mismo. Sin em- 
bargo, existen diferencias importantes entre estos tipos de requerimientos: 

1. Estabiendesarrollada lanocionde un ciclo de vidade seguridad que incluye todos los 
aspectos de la gestion de seguridad. El area de especificacion y gestion de la protec- 
cion todavia no esta madura y no existe un equivalente aceptado de ciclo de vida de 
proteccion. 

2. Sibienalgunas amenazas de la proteccion son especificas del sistema, muchas sonco- 
munes a todos los tipos de sistemas. Todos los sistemas deben protegerse a si mismos 
contra intrusiones, denegaciones de servicio, y otros. Porel contrario, las contingen- 
cias en sistemas de seguridad criticos son especificas del dominio. 

3. Las tecnicas y tecnologias de seguridad tales como encriptacion y dispositivos de 
autenticacion estan bastante maduras. Sin embargo, el uso efectivo de esta tecno- 
logia a menudo requiere un alto nivel de sofisticacion tecnica. Dicha tecnologia 
puede ser dificil de instalar, configurar y mantener actualizada. Como consecuen- 
cia, los gestores del sistema cometen errores ocasionando vulnerabilidades en el 
sistema. 

4. El predominio de un suministrador de software en los mercados del mundo implica 
que un enorme numero de sistemas se vea afectado por una violacion de la proteccion 
en sus programas. La diversidad de la infraestructura informatica es insuficiente y 
como consecuencia, es mas vulnerable a amenazas externas. Generalmente, los siste- 
mas de seguridad criticos estan especializados y hechos a medida; por lo tanto, no pue- 
de darse la situacion anterior. 

La aproximacion convencional (no informatica) para el analisis de la proteccion se basa en 
los activos aprotegery su valor en una organizacion. Por lo tanto, un banco proporcionaraalta 
seguridad en un area en la que se almacenen grandes cantidades de dinero en comparacion con 
otras areas publicas (porejemplo) en donde las perdidas potenciales estan limitadas. La mis- 
ma aproximacion se puede utilizarpara especificar la proteccion de sistemas informaticos. Un 
posible proceso de especificacion de proteccion se muestra en la Figura 9.8. 

Las etapas de este proceso son: 

1. Identification y evaluation de activos. Se identifican los activos (datos y programas) 
y su grado de proteccion requeridos. Dichaproteccion requerida depende del valor del 
activo, de forma que un fichero de contrasefias (por ejemplo) es normalmente mas va- 
lioso que un conjunto de paginas web publicas, yaque un ataque con exito sobre el fi- 
chero de contrasefias tendra consecuencias serias en todo el sistema. 

2. Analisis de amenazas y valoracion de riesgos. Se identifican posibles amenazas de 
proteccion y se estiman los riesgos asociados con cada una de estas amenazas. 

3. Asignacion de amenazas. Las amenazas identificadas se relacionan con los activos de 
forma que para cada activo identificado exista una lista de amenazas. 

4. Analisis de la tecnologia. Se evaluan las tecnologias disponibles y su aplicabilidad 
contra las amenazas identificadas. 
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5. Especificacion de lo\ requerimientos de proteccion. Se especifican los requerimientos 
de proteccion. En donde sea apropiado, estos identificaran explicitamente las tecno- 
logias de proteccion que pueden utilizarse para proteger al sistema contra las amena- 
zas identificadas. 

La especificacion de la proteccion y la gestion de la proteccion son esenciales para todos 
los sistemas criticos. Si un sistema no esta protegido, entonces esta sujeto a infecciones de vi- 
rus y gusanos, corrupcion y modificacion no autorizada de datos, y ataques de denegacion de 
servicio. Todo esto significa que no podemos estar seguros de que los esfuerzos realizados 
para asegurar la fiabilidad y seguridad sean efectivos. 

Diferentes tipos de requerimientos de proteccion hacen referencia a distintas amenazas con 
las que se puede enfrentar el sistema. Firesmith (Firesmith, 2003) identifica 10 tipos de re- 
querimientos de proleccion que pueden incluirse en un sistema: 

1. Los requerimientos de identification especifican si un sistema deberia identificar a sus 
usuarios antes de interaccionar con el. 

2. Los requerimientos de autenticacion especifican como son identificados los usuarios. 

3. Los requerimientos de autorizacion especifican los privilegios y permisos de acceso 
de los usuarios identificados. 

4. Los requerimientos de inmunidad especifican como un sistema deberia protegerse 
contra virus, gusanos, y amenazas similares. 

5. Los requerimientos de integridadespecifican como puede evitarse la corrupcion de los 
datos. 

6. Los requerimientos de detection de intrusiones especifican que mecanismos deberian 
utilizarse para detectar ataques al sistema. 

7. Los requerimientos de no rechazo especifican que una parte de la transaccion no pue- 
de negar su pertenencia a dicha transaccion. 

8. Los requerimientos de privacidad especifican como se deberia mantener la privacidad 
de los datos. 

9. Los requerimientos de auditoria de seguridad especifican como puede auditarse y 
comprobarse el uso del sistema. 
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Todos los usuarios del sistema deberian ser identificados utilizando su numero de car- 
net de biblioteca y su contrasena personal. 

Los privflegios de los usuarios deberian ser asignados segun el tipo de usuario (estu- 
diante, personal administrativo, personal de biblioteca). 

Antes de ejecutar cualquier orden, UBSYS deberla comprobar que el usuario tenga su- 
ficientes privilegios para acceder y ejecutar dicha orden. 

Cuando un usuario pide un documento, la orden de peticion deberla ser registrada. Los 
datos de registro mantenidos deberian incluir la hora de la peticion, la identification del 
usuarioy los articu los solicitados. 

Una vez al dia se deberia hacer una copia de seguridad de todos los datos del sistema 
ylas copias de seguridad deberian guardarse en un area de almacenamiento segura. 

No deberia permitirse a los usuarios tener simultaneamente mas de un login para 
UBSYS. 

10. Los requerimientos de seguridad de mantenimiento del sistema especifican como una 
aplicacion puede impedir los cambios que se hayan autorizado como consecuencia 
de una violacion accidental de sus mecanismos de seguridad. 

Por supuesto, no todos los sistemas necesitan todos estos requerimientos de proteccion. Los 
requerimientos especificos dependen del tipo de sistema, la forma de uso y los usuarios espe- 
rados. Como ejemplo, la Figura 9.9 muestra los requerimientos de proteccion que podrian in- 
cluirse en el sistema LIB SYS. 

9.4 Especificacion de la fiabilidad del software 

La fiabilidad es un concepto complejo que siempre se deberia considerar a nivel de sistema 
en lugar de a nivel de componente individual. Debido a que los componentes de un sistema 
son interdependientes, un fallo en un componente puede propagarse al resto del sistema y 
afectaral funcionamiento de otros componentes. En un sistema informatico, se deben consi- 
derar tres dimensiones cuando se especifique la fiabilidad del sistema en su totalidad: 

1. Fiabilidad del hardware. ^Cual es la probabilidad de que un componente hardware fa- 
lle y cuanto tiempo se tarda en reparardicho componente? 

2. Fiabilidad del software. ^,Cual es la probabilidad de que un componente software pro- 
duzca una salida incorrecta? Los fallos del software son distintos de los fallos del hard- 
ware en tanto que el software no se desgasta: este puede continuar funcionando co- 
rrectamente despues de que se haya producido un resultado incorrecto. 

3 . Fiabilidad del operador. iCus\ es la probabilidad de que el operador de un sistema co- 
meta un error? 

Todas estas dimensiones estan estrechamente relacionadas. Los fallos del hardware pue- 
den provocar la generacion de senales espurias que esten fuera del rango de las entradas es- 
peradas por el software. Despues, el software puede comportarse de forma impredecible. El 
comportamiento no esperado del sistema puede confundiral operador y provocarle estres. El 
operador puede entonces actuar de forma incorrecta y elegir entradas que son inadecuadas 
para la situacion de fallo actual. Ademas estas entradas confunden al sistema y generan mas 
errores. Por lo tanto, puede ocurriruna situacion en la que un fallo recuperable de un subsis- 
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temarapidamentepuedadar lugaraunproblemaserioquerequieraunareinicializacioncom- 
pleta del sistema. 

La fiabilidad de los sistemas deberia especificarse como un requerimiento no funcional que, 
idealmente, se exprese de forma cuantitativa utilizando una de las metricas expuestas en la sec- 
cion siguiente. Para cumplir los requerimientos de fiabilidad no funcionales, puede ser nece- 
sario especificar requerimientos funcionales y de diseiio adicionales que determinen como los 
fallos pueden ser evitados o tolerados. Ejemplos de estos requerimientos de fiabilidad son: 

1 . Se deberia establecer un rango predefinido para todos los valores que introduce el ope- 
rador, y el sistema deberia comprobar que todas las entradas del operador estan den- 
tro de este rango predefinido. 

2. Como parte del proceso de inicializacion, el sistema deberia comprobar los bloques 
defectuosos de todos los discos. 

3 . Se deberia utilizar la programacion de / ; versiones para implementar el sistema de con- 
trol de frenado. 

4. El sistema deberia implementarse utilizando un subconjunto seguro de Ada y deberia 
verificarse por medio de analisis estatico. 

No existen reglas sencillas que se puedan utilizar para derivar requerimientos fiables fun- 
cionales. En las organizaciones que desarrollan sistemas criticos, generalmente existe un co- 
nocimiento organizacional sobre posibles requerimientos de fiabilidad y como afectan estos a 
la fiabilidad real de un sistema. Estas organizaciones pueden especializarse en tipos especifi- 
cos de sistemas, como los sistemas de control ferroviario, de tal forma que los requerimientos 
de fiabilidad, una vez derivados, se reutilizan en un amplio rango de sistemas. Cuanto mayor 
es el nivel de integridad de la seguridad (comentado anteriormente), requerido en sistemas de 
seguridad criticos, es mas probable que los requerimientos de fiabilidad sean mas estrictos. 

9.4.1 Metricas de fiabilidad 

Las metricas de fiabilidad fueron disenadas inicialmente para componentes hardware. Los fa- 
llos en los componentes hardware son inevitables debido a factores fisicos tales como la abra- 
sion mecanicay el calentamiento electrico. Los componentes tienen un periodo de vida limi- 
tado y esto se refleja en la metrica de fiabilidad de hardware que mas se utiliza, tiempo medio 
entre fallos (MTTF). El MTTF es el tiempo medio durante el cual se espera que un compo- 
nente funcione. Normalmente, un fallo de un componente hardware es permanente; por lo tan- 
to tambien es significativo el tiempo medio de reparacion (MTTR), que refleja el tiempo ne- 
cesario para reparar o reemplazar el componente. 

Sin embargo, estas metricas hardware no son directamente aplicables a la especificacion 
de la fiabilidad del software debido a que los fallos de los componentes software son a me- 
nudo transitorios mas que permanentes. Solamente se manifrestan con algunas entradas. Si los 
datos no estan danados, a menudo el sistema puede continuar funcionando despues de que 
ocurra un fallo. 

Las metricas que se han utilizado para especificar la fiabilidad y disponibilidad del soft- 
ware se muestran en la Figura 9.10. La eleccion de que metrica deberia utilizarse depende del 
tipo de sistema sobre el que se aplica y de los requerimientos del dominio de la aplicacion. 
Algunos ejemplos de tipos de sistemas en donde se utilizan estas metricas son: 

1. Probabilidad de fallos en la petition. Esta metrica es la mas adecuada para sistemas 
en lo que los servicios se demandan a intervalos de tiempo impredecibles o relativa- 
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POFOD Probabilidad de fallos en la petid6n 


La probabilidad de que el sistema faHe euando se soHcite una petkion de servi- 
cio. Un POFOD de 0,001 stgnHka que una de cada 1.000 petkiones de sen/ion 
conduce a un fallo. 


ROCOF lass de ocurrenda de fa Bos 


La frecuencia de ocurrenda con la que es probable que ocurra un comporta- 
miento inesperado. Un ROCOF de 2/100 signffica que es probable que ocurran 
dos (alios en cada 100 unidades de tiempo de furidonamiento. Esta mAtrica se 
conoce algunas veces como la intena'dad de fallos. 


MTTF Tiempo medio entre faltos 


0 tiempo medio entre fallos de sistema observados. Un MTTF de 500 signifies 
que puede esperarse un fallo cada 500 unidades de tiempo. 


AVAIL Disponibilidad 


La probabilidad de que el sistema est* disponiWe para su utilizacion en un mo- 
menta) determinado. Una disponibilidad de 0,998 signifka que el sistema es pro- 
bable que este disponiWe durante 998 de cada 1 .000 unidades de tiempo. 



Figura 9.10 M&ricas de fiabilidad. 



mente largos y en los que existen serias consecuencias si el servicio pedido no se pro- 
porciona. Se podrlautilizar para especificar sistemas deproteccioncomo la fiabilidad 
de un sistema de liberacion de presion en una planta quimica o el sistema de apagado 
de emergencia en una planta de energia. 

2. Tasa de ocurrencia de fallos. Esta metrica deberia utilizarse en donde se hagan peti- 
ciones regulares de los servicios del sistema y en donde sea importante que estos ser- 
vicios se proporcionen correctamente. Deberia utilizarse en la especificacion de un sis- 
tema de cajero automatico que procesa transacciones de clientes o en un sistema de 
reservas de hoteles. 

3. Tiempo medio entre fallos. Esta metrica deberia utilizarse en sistemas con transaccio- 
nes largas; esto es, en donde la gente utiliza el sistema durante largos periodos de tiem- 
po. El MTTF deberia ser mayor que la longitud media de cada transaccion. Ejemplos 
de sistemas en los que podria utilizarse esta metrica son sistemas de procesamiento de 
texto y sistemas CAD. 

4. Disponibilidad. Esta metrica deberia utilizarse en sistemas que no se detienen y en los 
que los usuarios esperan que el sistema proporcione un servicio continuado. Ejemplos 
de tales sistemas son los sistemas de centralita telefonica y sistemas de senalizacion 
ferroviaria. 

Hay tres tipos de mediciones que pueden realizarse cuando se valora la fiabilidad de un sis- 
tema: 

1. El numero de fallos del sistema dado un numero de peticiones de servicios del siste- 
ma. Se usa para medir el POFOD. 

2. El tiempo (o numero de transacciones) transcurrido entre fallos del sistema. Se utili- 
za para medir el ROCOF y el MTTF. 

3. El tiempo consumido en reparar o reiniciar el sistema cuando ocurre un fallo. Dado 
que el sistema debe estar disponible continuamente, este se utiliza para medir el 
AVAIL. 

Las unidades de tiempo que se pueden utilizar en estas metricas son fechas de calendario, 
tiempo de procesador o algunas unidades discretas, como por ejemplo el numero de transac- 
ciones. En sistemas que emplean mucho tiempo esperando responder a una peticion de ser- 
vicio, como los sistemas de centralita telefonica, la unidad de tiempo que deberia utilizarse 
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es el tiempo de procesador. Si se utilizan fechas de calendario, entonces esto tambien inclu- 
ye el tiempo durante el que el sistema no esta haciendo nada. 

Las fechas de calendario son una unidad de tiempo adecuada para sistemas que estan en 
continuo funcionamiento. Porejemplo, los sistemas de monitorizacion tales como sistemas 
de alarma y otros tipos de sistemas de control de procesos pertenecen a esta categoria. Los 
sistemas que procesan transacciones tales como cajeros automaticos y sistemas de reservas 
de billetes de avion tienen una carga variable dependiendo de la hora del dia. En estos ca- 
sos, la unidad de «tiempo» utilizada deberia ser el numero de transacciones; por ejemplo, el 
ROCOF podria ser el numero de transacciones sin exito en « miles de transacciones. 



9.4.2 Requerlmlentos de flabllldad no funclonales 

En muchos documentos de requerimientos del sistema, los requerimientos de fiabilidad no se 
especifican cuidadosamente. Las especificaciones de fiabilidad son subjetivas y no mensura- 
bles. Por ejemplo, frases como «E1 software deberia ser fiable en condiciones normales de 
uso» carecen de significado. Frases cuasi cuantitativas como «E1 software debera exhibirno 
mas de n defectos/1 .000 Hneas» son igualmente inutiles. Es imposible medirel numero de de- 
fectos/1.000 lineas de codigo puesto que no se puede decircuando se han descubierto todos 
los defectos. Ademas, la frase no significa nada en lo que se refiere al comportamiento dina- 
mico del sistema. Son los fallos de funcionamiento del software y no los defectos del software 
los que afectan a la fiabilidad de un sistema. 

Los tipos de fallos que pueden ocurrir son especificos del sistema y las consecuencias de 
un fallo del sistema dependen de la naturaleza de ese fallo. Cuando se redacte una especifi- 
cacion de fiabilidad, habria que identificar los diferentes tipos de fallos y pensar sobre si es- 
tos deberian ser tratados de forma diferente en la especificacion. En la Figura 9.1 1 se mues- 
tran ejemplos de diferentes tipos de fallos. Obviamente pueden ocurrir combinaciones de 
estos, como por ejemplo un fallo que sea transitorio, recuperable y corruptivo. 

La mayoria de los sistemas grandes estan compuestos por varios subsistemas con diferen- 
tes requerimientos de fiabilidad. Puesto que el software que tiene una fiabilidad alta es caro, 
deberia realizarse una valoracion de los requerimientos de fiabilidad para cada subsistemapor 
separado en lugar de imponer el mismo requerimiento de fiabilidad para todos los subsiste- 
mas. Esto evita imponer altos requerimientos de fiabilidad en aquellos subsistemas en los que 
no es necesario. 

Los pasos que se requieren pura establecer una especificacion de la fiabilidad son: 

1 . Para cada subsistema, identificar los tipos de fallos de funcionamiento del sistema que 
pueden ocurrir y analizar las consecuencias de dichos fallos. 



Figura 9.11 

Clasif icacion 
de fallos 

de funcionamiento. 





Transitorio 


Ocurre sotamente con ciertas entradas. 


Permanente 


Ocurre con todas las entradas. 


Recuperable 


El sistema puede recuperarse sin la intervencion del operador. 


Irrecuperable 


Es necesaria la intervenci6n del operador para recuperarse del fallo. 


No corruptivo 


El fallo no corrompe el esta do del sistema o los datos. 



Corruptivo 



El fallo corrompe el estado del sistema o los datos. 
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2. A partirdel analisis de fallos del sistema, dividir los fallos en clases. Un punto de par- 
tida razonable es utilizar los tipos de fallos mostrados en la Figura 9.1 1. 

3. Para cada clase de fallo identificada, definir el requerimiento de fiabilidad utilizando 
unametricade fiabilidad adecuada. Noes necesario utilizar lamismametricaparadi- 
ferentes clases de fallos. Si un fallo requiere alguna intervencion para poder recupe- 
rar el sistema, la metrica mas apropiada podria ser la probabilidad de fallos en la pe- 
ticion. Cuando es posible la recuperacion automatica y el efecto del fallo es la causa 
de una molestia para el usuario, ROCOF podria ser la mas adecuada. 

4. Donde sea apropiado, identificar los requerimientos de fiabilidad funcionales que de- 
finen la funcionalidad del sistema para reducir la probabilidad de fallos criticos. 

Como ejemplo, considere los requerimientos de fiabilidad para un cajero automatico 
(ATM) . Suponga que cada maquina en la red se utiliza alrededor de 300 veces al dia. El tiem- 
po de vida del hardware del sistema es 5 anos y el software se actualiza normalmente cada 
afio. Por lo tanto, durante el tiempo de vida de una version del software comercializada, cada 
maquina gestionara alrededor de 100.000 transacciones. Un banco tiene 1.000 maquinas en 
su red. Esto significa que hay 300.000 transacciones sobre la base de datos central al dia (es 
decir, 100 millones por afio). 

La Figura 9.12 muestra posibles clases de fallos y posibles especificaciones de fiabilidad 
para diferentes tipos de fallos del sistema. Los requerimientos de fiabilidad establecen que es 
aceptable que una caida permanente en una maquina ocurra una vez cada tres afios. Esto sig- 
nifica que, en promedio, una maquina de la red bancaria podria verse afectada cada dia. Por 
el contrario, los defectos que conllevan que una transaccion sea cancelada ocurren con rela- 
tiva frecuencia. El unico efecto de dichos fallos solamente es una inconveniencia menor al 
usuario. 

En condiciones ideales, los defectos que corrompen la base de datos nunca deberian ocu- 
rrir durante el tiempo de vida del software. Por lo tanto, el requerimiento de fiabilidad que po- 
dria utilizarse para esto es que la probabilidad de que ocurra un fallo corruptivo cuando se re- 
aliza una peticion es menor que 1 en 200 millones de transacciones. Esto es, durante el tiempo 
de vida de una version del software para un A T M , nunca deberia ocurrir un error que provo- 
cara la corrupcion de la base de datos. 

Sin embargo, un requerimiento de fiabilidad como este no puede realmente probarse. Con- 
sideremos, por ejemplo, que cada transaccion consume un segundo de tiempo de maquina y 
que puede construirse un simuladorpara la red de ATMs. La simulacion de las transacciones 
que tienen lugar en un solo dia en toda la red tardara un tiempo de 300.000 segundos. Esto es 
aproximadamente 3,5 dias. Claramente este periodo puede reducirse disminuyendo el tiem- 




Permanente, no corruptivo El sistema deja de funcionar con ROCOF 

cualquier tarjeta que se introduzca. 1 ocunencia/1.000 d(as 
El software debe reinkializarse para 
corregir el fallo. 



Trans itorro, no corruptivo 



Figura 9.12 

Especificacion 
de fiabilidad para 
un ATM. 



Transitorio, corruptivo 



La banda magnftica de datos de una 
tarjeta no daftada no puede leerse. 



ROCOF 

I en 1 .000 transacoones 



Un patron de transacciones en la red 
provoca que la base de datos 
se corrompa. 



iNo cuantrficable! 
No deberia ocurrir nunca 
durante el tiempo de vida 
del sistema. 
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po de transaccion y utilizando varios simuladores. Pero, aun asi, es muy dificil probar el sis- 
tema para validar la especificacion de fiabilidad. 

Es imposible validar requerimientos cualitativos que requieren un alto nivel de fiabilidad. 
Por ejemplo, pensemos en un sistema desarrollado para utilizarse en una aplicacion de segu- 
ridad critico. Dicho sistema no deberia fallar nunca durante el tiempo total de vida del siste- 
ma. Suponga que deben instalarse 1 .000 copias de dicho sistema, y que este se «ejecuta» 1 .000 
veces por segundo. El tiempo de vida estimado del sistema es de 10 afios. El numero total es- 
timado de ejecuciones del sistema es aproximadamente 3 * 10' 4 . No merece lapena especifi- 
car que la tasa de ocurrencia de fallos deberia ser de l/10 ls ejecuciones (esto permite algun 
factor de seguridad) puesto que usted no puede probar el sistema durante todo este tiempo para 
validar este nivel de fiabilidad. 

Como otro ejemplo adicional, considere los requerimientos de fiabilidad para el sistema 
de suministro de insulina. El sistema suministra insulina varias veces al dia y monitoriza el 
nivel de glucosa en la sangre varias veces por hora. Debido a que el uso del sistema es inter- 
mitente y las consecuencias de un fallo son serias, la metrica de fiabilidad mas adecuada es 
POFOD (probabilidad de fallo en la peticion). 

Un fallo en el suministro de insulina no tiene implicaciones de seguridad inmediatas, por 
lo que los factores comerciales mas que los de seguridad determinan el nivel de fiabilidad re- 
querida. Los costes del servicio son altos debido a que los usuarios necesitan un servicio de 
reparacion y sustitucion rapido. Es obligacion del fabricante limitar el numero de fallos per- 
manentes que requieren reparacion. 

De nuevo, se pueden identificar dos tipos de fallos: 

1. Fallos transitorios que se pueden reparar mediante acciones del usuario, como reini- 
cializar o recalibrar la maquina. Para estos tipos de fallos, puede ser aceptable un va- 
lor relativamente bajo de POFOD (por ejemplo, 0,002). Esto significaque un fallo pue- 
de ocurrir cada 500 peticiones realizadas a la maquina. Esto es aproximadamente una 
vez cada 3,5 dias. 

2. Fallos permanentes que requieren que la maquina sea reparada por el fabricante. La 
probabilidad de este tipo de fallos deberia ser mucho menor. Aproximadamente una 
vez al alio es lo minimo, por lo que POFOD no deberia ser mayor de 0.00002. 



PUNTOS CLAVE 

• El analisis de riesgos es una actividad clave en el proceso de especificacion de sistemas crftlcos. Dicho anali- 
sis implica la identification de riesgos que pueden provocar accidentes o incidentes. Los requerimientos del 
sistema se establecen entonces para asegurar que estos riesgos no ocurran o, si ocurren, no provoquen un 
incidente. 

• El analisis de riesgos es el proceso de valorar la probabilidad de que un riesgo provoque un accidente. El ana- 
lisis de riesgos identifica riesgos cnticos en el sistema que deberian evitarse y los clasifica de acuerdo con su 
gravedad. 

Para especificar los requerimientos de seguridad, se deberian identificar los activos que tienen que protegerse 
y definir co mo deberian utilizarse las tecnicas y tecnologias de proteccion para proteger estos activos. 
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• Los requerimientos de f labllldad deberian deflnfese de fcima cuantltatlva en la especificacion de los lequeri- 
mtentos del stetema. 

• Bdsten varias metrlcas de fiabilidad, tal cotno b probabMad de falos en ta petlclon (PORK)), tasa de ocu- 
rrencta de fallos, tiempo medb entae falos (IVHTF) y dsponHMad. la metrlca mas apropiada para in siste- 
ma especi'flco depende del ttpo de stetema y del domno de la apllcacldn. Rieden uUbarse metrlcas cfferen- 
tes para subsbtemas dferentes. 

• Las espBcHc a ctofi B S de fiabilidad no fundonales pueden conduce* a lequerirnienlDS functa nates del stetema 
que defhen tas caracteristlcas del mbmo y cuya funclon es reducr el numero de falos del stetema y, par lo 
tanto, hcnementar la fiabSdad. 

• B coste de desarrolary vaidar ma especificacion de BabMad del stetema puede ser muy atto. Las onjant- 
zadones deben ser rea f lst a s sobre si estos castes merecen b pena. Estos estan cbiamente Justhlcados en sis- 
temas en donde es critlco in fundoriamiento flable, como sistemas de centralta telefonlca o en sistemas en 
donde tos fartos pueden prowocar gandes perdldas econdmlcas. Piababbmente no este JusOflcado par mu- 
chas ttpos de s b tema s cienti'ficos o de negodo. Estos tJenen requerimientos de fiabilidad modestos, ya que 
los costes de falo son sfcnptemente rebasos en el procesamtenlp, y es sencBo y lebraVamente barato recu- 
perarse de dbhos falos. 



LECTURAS ADICIONALES 



«Security use cases». Un buen articulo, disponible en la web, que se centra en como los casos de uso se pueden 
utilizar en la especificacion de (aproteccion. Elautortambien tiene variosbuenos articulos sobre especificacion 
de seguridad a los que hace referencia en este articulo. [D. G. Firesmith,/ourno/ofOb/ect Technology, 2 (3), mayo- 
junio de 2003.] 

«Requeriments Definition for survivable network systems». Trata los problemas de definicion de requerimientos para 
sistemas en los que es importante la supervivencia, relacionada esta con ta disponibilidad y la proteccion. (R. C. Lin- 
ger et a/., Proc. /Cfff 98, IEEE Press, 1998.) 

Requirements Engineering: A Good Practice Guide. Este libro incluye una section sobre la especificacion de siste- 
mas criticos y un estudio del uso de metodos formales en la especificacion de sistemas criticos. (I. Sommerville y P. 
Sawyer, 1997, John Wiley and Sons.) 

Safeware: System Safetyand Computers. Este es un estudio complete de todos los aspectos de los sistemas de se- 
guridad criticos. Hace especial hincapie en su description del analisis de contingencias y la derivation de requeri- 
mientos a partir de dicho analisis. (N. Leve son, 1995, Addison-Wesley.) 



EJERCICIOS 



9. 1 Explique porque los limites deltriangulo de riesgos mostrado en la Figurag.2 es susceptible de cambio con 
el tiempo y con las actitudes sociales cambiantes. 



CAPITULO 9 • Ejercicios 195 



92 En el sistema de suministro de insulina, el usuario tiene que cambiar la aguja y suministrar insulina en in- 
tervalos regulares y tambien puede cambiar la dosis maxima para un dia o bien la dosis maxima diaria que 
se puede suministrar. Sugiera tres errores de usuario que podrian ocurrir y proponga requerimientos de se- 
guridad que podrian evitar que estos errores produjeran un accidente. 

9.3 Un sistema software de seguridad critico para el tratamiento de pacientes con cancer tiene dos componen- 
tes principales: 

• La maquina deterapiade radiacion que suministra dosis controladas de radiacion a los puntos del tumor. 
Esta maquina se controla por medio de un sistema software embebido. 

• Una base de datos de tratamientos que incluye los detalles del tratamiento dado a cada paciente. Los re- 
querimientos del tratamiento se introducen en esta base de datos y automaticamente se descargan en 
la maquina para la terapia de radiacion. 

Identifique tres contingencias que puedan surgir en este sistema. Para cada contingencia sugiera un re- 
querimiento defensivo que reduzca la probabilidad de que estas contingencias provoquen un accidente. Ex- 
plique por que la defensa sugerida por usted es probable que reduzca el riesgo asociado a ta contingencia. 

94 Describa tres diferencias importantes entre los procesos de especificacion de seguridad y especificacion de 
proteccion. 

9.5 Sugiera como puede modificarse un analisis de arbol de defectos para serusado en la especificacion de la 
proteccion. Las amenazas en un sistema de proteccion critico son analogas a las contingencias en un siste- 
ma de seguridad critico. 

9.6 ^Cual es la diferencia fundamental entre los fallos de funcionamiento del hardware y del software? Dada esta 
diferencia, explique por que las metricas de fiabilidad del hardware son a menudo inadecuadas para medir 
la fiabilidad del software. 

9.7 Explique por que es practicamente imposible validar las especificaciones de fiabilidad cuando estas se ex- 
presan en terminos de un numero muy pequeno de fallos sobre el tiempo total de vida de un sistema. 

9.8 Sugiera metricas de fiabilidad apropiadas para las siguientes clases de sistemas software. De razones para 
su eleccion de dichas metricas. Prediga el uso de estos sistemas y sugiera valores apropiados para las me- 
tricas de fiabilidad: 

• Un sistema que monitoriza pacientes en una unidad de cuidados intensivos de un hospital. 

• Un procesador de texto. 

• Un sistema de control de maquinas expendedoras automaticas. 

• Un sistema de control de frenado en un coche. 

• Un sistema para controlar una unidad de refrigeracion. 

• Un generador de informes administrativos. 

9.9 Usted es responsable de escribir la especificacion para un sistema software que controla una red de termi- 
nales EPOS (punto de venta electronico) en un almacen. El sistema acepta informacion de codigo de barras 
desde un terminal, consulta una base de datos de productos y devuelve el nombre del articulo y su precio 
al terminal para su visualizaron. El sistema debe estar disponible continuamente durante las horas en las 
que esta abierto el almacen. 

Elija las metricas apropiadas para especificar la fiabilidad de dicho sistemajustificando su eleccion, y escriba 
una especificacion de fiabilidad plausible que tenga en cuenta el hecho de que algunos defectos son mas 
serios que otros. 

Sugiera cuatro requerimientos funcionales que podrian generarse para este sistema de almacen para me- 
jorar la fiabilidad del sistema. 
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9.10 Un sistema de proteccion ferroviario frena automaticamente un tren si el Hmite de velocidad se excede en 
un tramo de via o si el tren entra en un tramo de via que esta seflalizado con una luz roja (es decir, no se de- 
berla haber entrado en ese tramo). Elijaunametricade fiabilidadjustificando surespuesta, quepodrlausar- 
se para especificar la fiabilidad requerida para dicho sistema. 

Hay dos requerimientos esenciales de seguridad para dicho sistema: 

• El tren no deberla entrar en un tramo de pista seflalizado con una luz roja. 

• El tren no deberla exceder el Hmite de velocidad especificado para un tramo de via. 

Suponiendo que elestado de la serial luminosay el Hmite de velocidad para el tramo de via se transmite des- 
de el software del cuadro de mandos al tren antes de que este entre en un tramo de pista, proponga cinco 
posibles requerimientos funcionales del sistema para el software del cuadro de mandos que puedan deri- 
varse de los requerimientos de seguridad del sistema. 

9.11 Los ingenieros software que trabajan en la especificacion y desarrollo de sistemas relacionados con la se- 
guridad ^deberian estar certificados profesionalmente de alguna forma? Justifique su respuesta. 

9.12 Como experto en proteccion de computadoras, usted ha sido requeridoporuna organizacion que realizauna 
campana por los derechos de las vlctimas de torturas y le han pedido que ayude a la organizacion a conse- 
guiraccesos no autorizados a los sistemas informaticos de una compania britanica. Esto les ayudaria a con- 
firmar o desmentir que esta compania esta vendiendo equipamiento que se usa directamente en la tortura 
de prisioneros pollticos. Comente los dilemas eticos que esta solicitud provocay como podrla usted reac- 
cionarante esta peticion. 
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Objetivos 

El objetivo de este capitulo es introducir las tecnicas de 
especificacion formal que se pueden usar para anadir detalle a una 
especificacion de requerimientos de un sistema. Cuando haya 
leido este capitulo: 

• comprendera por que las tecnicas de especificacion formal 
ayudan a descubrir problemas en los requerimientos del 
sistema; 

• comprendera el uso de tecnicas algebraicas de especificacion 
formal para definir las especificaciones de jnterfaz; 

• comprendera como las tecnicas formales basadas en modelos 
formales se usan para especificar el comportamiento. 

Contenidos 

10.1 Especificacion formal en el proceso del software 

10.2 Especificacion de interfaces de subsistemas 

10.3 Especificacion del comportamiento 
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En las disciplinas de ingenieria «tradicionales», tales como la ingenieria civil y la electrica, 
el progreso normalmente ha conducido al desarrollo de mejores tecnicas matematicas. La in- 
dustria de ingenieria no ha tenido dificultad en aceptar la necesidad del analisis matematico 
y en incorporareste en sus procesos. El analisis matematico es una parte rutinaria del proce- 
so de desarrollo y validacion del diseno de un producto. 

Sin embargo, la ingenieria del software no ha seguido el mismo camino. A pesar de que 
hasta ahorahan sidomas de 30 anos de investigacionen lautilizacionde tecnicas matemati- 
cas en el proceso del software, estas tecnicas han tenido un impacto limitado. Los denomina- 
dos metodos formales de desarrollo del software no son muy utilizados en el desarrollo de 
software industrial. Lamayoriade las companias de desarrollo de software no consideran ren- 
table aplicarlos a sus procesos del software. 

La denominacion metodos formales se usa para referirse a cualquier actividad relacionada 
con representaciones matematicas del software, incluyendo la especificacion formal de siste- 
mas, analisis y demostracion de la especificacion, el desarrollo transformacional y la verifi- 
cacion de programas. Todas estas actividades dependen de una especificacion formal del soft- 
ware. Una especificacion formal del software es una especificacion expresada en un lenguaje 
cuyo vocabulario, sintaxis y semantica estan formalmente definidos. Esta necesidad de una 
definicion formal significa que los lenguajes de especificacion deben basarse en conceptos 
matematicos cuyas propiedades se comprendan bien. La rama de las matematicas usada es la 
de matematica discreta, y los conceptos matematicos provienen de la teoria de conjuntos, la 
logica y el algebra. 

En la decada de los 80, muchos investigadores de ingenieria del software propusieron que 
el uso de metodos formales de desarrollo era la mejor forma de mejorar la calidad del soft- 
ware. Argumentaban que el rigor y el analisis detallado, que son una parte esencial de los me- 
todos formales, podrian dar lugar a programas con menos errores y mas adecuados a las ne- 
cesidades de los usuarios. Predijeron que, en el siglo xxi, una gran proporcion del software 
estaria desarrollado usando metodos formales. 

Claramente, esta prediccion no se ha hecho realidad. Existen cuatro razones principales 
para esto: 

1. Una ingenieria del software exitosa. E 1 uso de otros metodos de ingenieria del soft- 
ware como los metodos estructurados, gestion de configuraciones y ocultacion de 
la informacion en el diseno del software y procesos de desarrollo ha conducido a 
mejoras en la calidad del software. La gente que sugirio que la unica forma de me- 
jorar la calidad del software era usando metodos formales estaba claramente equi- 
vocada. 

2. Cambios en el mercado. En la decada de los 80, la calidad del software fue vista como 
un problema clave de la ingenieria del software. Sin embargo, desde entonces, la cues- 
tion critica para muchas clases de desarrollo del software no es la calidad, sino la opor- 
tunidad de mercado. El software debe desarrollarse rapidamente, y los clientes estan 
dispuestos a aceptar software con algunos defectos si se les entrega rapidamente. Las 
tecnicas para el desarrollo rapido del software no funcionan de forma efectiva con las 
especificaciones formales. Por supuesto, la calidad todavia es un factor importante, 
pero debe lograrse en el contexto de entrega rapida. 

3. Ambito limitado de los metodos formales. Los metodos formales no son muy apro- 
piados para la especificacion de interfaces de usuario e interacciones del usuario. El 
componente de interfaz de usuario se ha convertido en una parte cada vez mayor de la 
mayoria de los sistemas, de manera que realmente solo pueden usarse metodos for- 
males cuando se desarrollan las otras partes del sistema. 
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4. Escalabilidad limitada de los metodos formales. Los metodos formales todavia no son 
muy escalables. La mayoria de los proyectos con exito que han usado estas tecnicas 
han estado relacionados con nucleos de sistemas criticos relativamente pequeflos. A 
medida que los sistemas incrementan su tamafio, el tiempo y esfuerzo requerido para 
desarrollar una especificacion formal crece de forma desproporcionada. 

Estos factores implican que la mayoria de las empresas que desarrollan software no esten 
dispuestas a arriesgarse a usar metodos formales en sus procesos de desarrollo. Sin embargo, 
la especificacion formal es una forma excelente de descubrir errores en la especificacion y 
presentar la especificacion del sistema de forma no ambigua. Las organizaciones que han he- 
cho una inversion para el uso de metodos formales presentan menos errores en el software en- 
tregado sin un incremento en los costes de desarrollo. Parece que los metodos formales pue- 
den ser rentables si su uso se limita a partes del nucleo del sistema y si las companias estan 
dispuestas a realizar una alta inversion inicial en esta tecnologia. 

El uso de metodos formales esta creciendo en el area del desarrollo de sistemas criticos, 
en donde las propiedades emergentes del sistema tales como seguridad, fiabilidad y protec- 
cion son muy importantes. El alto coste de los fallos de funcionamiento en estos sistemas im- 
plica que las companias estan dispuestas a aceptar los costes elevados iniciales de los meto- 
dos formales para asegurar que su software es tan confiable como sea posible. Tal y como se 
comenta en el Capitulo 24, los sistemas criticos tienen unos costes de validacion muy altos, 
y los costes de fallos de funcionamiento del sistema son importantes y crecientes. Los meto- 
dos formales pueden reducir estos costes. 

Los sistemas criticos en los que los metodos formales se han aplicado con exito incluyen 
un sistema de informacion de control de trafico aereo (Hall, 1996), sistemas de sefializacion 
dc rcdcs fcrroviarias (Dchbonci y Mcjia, 1995), sistemas dc naves cspacialcs (Eastcrbrook el 
ah, 1998) y sistemas de control medico (Jacky etal., 1997; Jacky, 1995). Los metodos for- 
males han sido utilizados tambien para la especificacion de herramientas software (Neil etal., 
1998), la especificacion de parte de los sistemas CICSdelBM (Wordsworth, 1991) yun ker- 
nel de un sistema de tiempo real (Spivey, 1990). El metodo de sala limpia (Cleanroom me- 
thod) de desarrollo de software (Prowell etal., 1999) utiliza argumentos formales que son co- 
dificados de acuerdo con su especificacion. Debido a que el razonamiento sobre laproteccion 
de un sistema tambien es posible si se desarrolla una especificacion formal, es probable que 
los sistemas protegidos constituyan un area importante para el uso de los metodos formales 
(Hall y Chapman, 2002). 

10.1 Especificacion formal en el proceso del software 

El desarrollo de sistemas criticos normalmente implica un proceso de software que utiliza un 
plan basado en el modelo de ciclo de desarrollo en cascada explicado en el Capitulo 4. Tanto 
los requerimientos del sistema como el diseno se expresan con detalle y son analizados cui- 
dadosamente antes de que comience la implementacion. Si se desarrolla una especificacion 
formal del software, esta normalmente tiene lugar despues de que se hayan especificado los 
requerimientos del sistema, pero antes del diseno detallado de dicho sistema. Aqui hay un es- 
trecho bucle de realimentacion entre la especificacion detallada de los requerimientos y la es- 
pecificacion formal. Tal y como se indica mas adelante, uno de los beneficios de la especifi- 
cacion formal es la capacidad para descubrir problemas y amb igiiedades en los requerimientos 
del sistema. 
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Flgura 10.1 Especificacion y diseno. 

La implicacion del cliente disminuye y la implicacion del contratante del software se in- 
crementa a medida que se afiade mas detalle a la especificacion del sistema. En etapas tem- 
pranas del proceso, la especificacion deberia ser «orientada al cliente». Deberia redactarse la 
especificacion para que el cliente la pueda comprender, y deberia hacerse el menor numero 
de asunciones posibles sobre el diseno del software. Sin embargo, la etapa final del proceso, 
que es la construccion de una especificacion completa, consistente y precisa, esta orientada 
principalmente al contratante del software. Este especifica los detalles de la implementacion 
del sistema. Puede utilizarse un lenguaje formal en esta etapa para evitar la ambiguedad en la 
especificacion del software. 

La Figura 10. 1 muestra las etapas de la especificacion del software y su interfaz con el pro- 
ceso de diseno. Estas etapas de especificacion no son independientes ni es preciso que se des- 
arrollen en la secuencia indicada. La Figura 10.2 muestra las actividades de especificacion y 
diseno que pueden llevarse a cabo de forma paralela. Existe una relacion bidireccional entre 
cada etapa del proceso. La informacion circula desde el proceso de especificacion al de dise- 
no y viceversa. 

A medida que se desarrolla la especificacion con detalle, se incrementa el conocimiento so- 
bre dicha especificacion. La creacion de una especificacion formal obliga a realizar un analisis 
detallado del sistema que normalmente revela errores e incongruencias en la especificacion in- 
formal de requerimientos. Esta deteccion de errores es probablemente el argumento mas poten- 
te para desarrollar una especificacion formal (Hall, 1990). La especificacion formal ayuda a 
descubrir problemas de los requerimientos que pueden ser muy caros de corregir mas tarde. 

Dependiendo del proceso usado, los problemas de la especificacion descubiertos durante 
el analisis formal podrian conducir a cambios en la especificacion de requerimientos si esta 
no ha sido acordada. Si la especificacion de requerimientos ha sido acordaday se incluye en 
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el contrato del desarrollo del sistema, habria que plantear al cliente los problemas que ha en- 
contrado. Este ultimo es entonces quien deberia decidir como tendrian que resolverse antes 
de empezar con el proceso de diseno del sistema. 

El desarrollo y analisis de una especificacion formal desplaza las cargas de los costes de 
desarrollo hacia las primeras etapas del mismo. La Figura 10.3 muestra como los costes del 
proceso del software es probable que se vean afectados por el uso de una especificacion for- 
mal. Cuando se usaun proceso convencional, los costes de validacion constituyen alrededor 
del 50% de los costes de desarrollo, y los costes de implementacion y diseno constituyen al- 
rededor de dos veces los costes de especificacion. Con la especificacion formal, los costes de 
especificacion e implementacion son comparables, y los costes de validacion del sistema se 
reducen de forma significativa. Asi como el desarrollo de una especificacion formal descubre 
problemas en los requerimientos, tambien se evita el volver a realizar el trabajo para corregir 
dichos problemas una vez disenado el sistema. 

Se han utilizado dos aproximaciones fundamentales para redactar especificaciones deta- 
lladas para sistemas de software industriales. Estas son: 

1 . Una aproximacion algebraica, en la que el sistema se describe en funcion de las ope- 
raciones y sus relaciones. 

2. Una aproximacion basada en modelos, en la que se construye un modelo del sistema 
utilizando construcciones matematicas como conjuntos y sucesiones, y las operacio- 
nes del sistema se definen indicando como estas modifican el estado del sistema. 

Se han desarrollado diferentes lenguajes dentro de estas dos aproximaciones para especi- 
ficar sistemas concurrentes y secuenciales. La Figura 10.4 muestra ejemplos de lenguajes en 
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cada una de estos enfoques. Se puede veren esta tabla que la mayoria de estos lenguajes fue- 
ron desarrollados en la decada de los 80. Lleva varios anos refinar un lenguaje de especifica- 
cion formal, por lo que la mayor parte de la investigacion en especificacion formal se basa ac- 
tualmente en estos lenguajes mas que interesarse en inventar notaciones nuevas. 

El objetivo de este capitulo es introducir ambas aproximaciones, tanto la algebraica como 
la basada en modelos. Los ejemplos mostrados deberian daruna idea de como la especifica- 
cion formal produce una especificacion precisa y detallada, pero no se pretende describir los 
detalles del lenguaje de especificacion, ni las tecnicas de especificacion o los metodos de ve- 
rificacion de programas. El lector puede descargaruna descripcion mas detallada de ambas 
tecnicas desde el sitio web del libro. 



10.2 Especificacion de interfaces de subsistemas 

Los grandes sistemas se descomponen normalmente en subsistemas que se desarrollan de for- 
ma independiente. Los subsistemas usan otros subsistemas; por lo tanto, una parte esencial 
del proceso de especificacion es la definicion de interfaces de subsistemas. Una vez que los 
interfaces se han acordado y definido, los subsistemas pueden entonces disenarse e imple- 
mentarse de forma independiente. 

Los interfaces de subsistemas se definen a menudo como un conjunto de objetos o com- 
ponentes (Figura 10.5). Estos describen los datos y operaciones a los que puede acceder a tra- 
ves de la interfaz del subsistema. Por lo tanto, se puede definiruna especificacion de la inter- 
faz de un subsistema combinando las especificaciones de los objetos que componen la 
interfaz. 

Es importante realizar especificaciones precisas de subsistemas debido a que los desa- 
rrolladores de los subsistemas deben escribir codigo que utiliza los servicios de otros sub- 
sistemas antes de que estos hayan sido implementados. La especificacion de la interfaz pro- 
porciona informacion a los desarrolladores de subsistemas para que estos conozcan que 
servicios estaran disponibles en otros subsistemas y como se puede acceder a ellos. Las es- 
pecificaciones de interfaces de subsistemas claras y no ambiguas reducen la posibilidad de 
malentendidos entre un subsistema que proporciona algun servicio y el subsistema que usa 
dicho servicio. 

La aproximacion algebraica fbe disenada originalmente para la definicion de interfaces de 
tipos abstractos de datos. En un tipo abstracto de datos, el tipo se define especificando el tipo 
de operaciones en lugar del tipo de representacion. Por lo tanto, esto es similar a una clase de 
objeto. El metodo algebraico de especificacion formal define el tipo abstracto de datos en fun- 
cion de las relaciones entre los tipos de operaciones. 

Objetos 
de la interfaz 



Figura 10.5 

Objetos de la 
interfaz del 
subsistema. 
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Guttag (Guttag, 1977) fue el primero en proponer esta aproximacion para la especificacion 
de tipos abstracter de datos. Cohen y otros (Cohen etal., 1986) muestrancomo latecnicapue- 
de ampliarse para completar la especificacion del sistema usando un ejemplo de un sistema 
de recuperacion de documentos. Liskov y Guttag (Liskov y Guttag, 1986) tambien tratan la 
especificacion algebraica de los tipos abstractos de datos. 

La estructura de la especificacion de un objeto se muestra en la Figura 10.6. El cuerpo de 
la especificacion tiene cuatro componentes: 

1. Una introduction que declara la clase (el nombre del tipo) de la entidad que se esta 
especificando. Una clase es el nombre de un conjunto de objetos con caracteristicas 
comunes. Es similar a un tipo en un lenguaje deprogramacion. La introduccion tam- 
bien puede incluiruna declaracion «imports», en la que se declaran los nombres de la 
especificacion que definen otras clases. Importaruna especificacion hace que estas cla- 
ses esten disponibles para ser usadas. 

2. Una parte de description, en donde las operaciones se describen informalmente. Esto 
hace que la especificacion formal sea mas facil de entender. La especificacion formal 
complementa esta descripcion proporcionando una sintaxis y semantica no ambiguas 
para las operaciones del tipo. 

3 . La parte de signatura define la sintaxis de la interfaz de la clase del obj eto o tipo abs- 
tracto de datos. La signatura describe los nombres de las operaciones que se definen, 
el numero y clase de sus parametros, y las clases de los resultados de las operaciones. 

4. La parte de axiomas define la semantica de las operaciones mediante la definicion de 
un conjunto de axiomas que caracterizan el comportamiento del tipo abstracto de da- 
tos. Estos axiomas relacionan las operaciones utilizadas para construir entidades de la 
clase definida con las operaciones empleadas para inspeccionar sus valores. 

El proceso del desarrollo de una especificacion formal de la interfaz de un subsistema 
comprende las siguientes actividades: 

1 . Estructura de la especificacion. Se organiza la especificacion informal de la interfaz 
en un conjunto de tipos abstractos de datos o clases de objetos. Se deberian definir in- 
formalmente las operaciones asociadas con cada clase. 

2. Nombrado de la especificacion. Se establece un nombre para la especificacion de 
cada tipo abstracto de datos, decide si estos requieren parametros y determina los nom- 
bres para las clases identificadas. 

3. Selection de las operaciones. Se elige un conjunto de operaciones para cada especi- 
ficacion basada en la funcionalidad identificadade la interfaz. Deberian incluirse ope- 
raciones para crear instancias de la clase, para modificar el valor de las instancias y 
para inspeccionar los valores de las instancias. Deben anadirse funciones a las ini- 
cialmente identificadas en la definicion informal de la interfaz. 
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4. Especificacion informal de las operaciones. Se redacta una especificacion informal 
de cada operacion. Deberia describirse como las operaciones afectan a la clase defi- 
nida. 

5. Definition de ta sintaxis. Se define la sintaxis de las operaciones y sus parametros. 
Esta es la parte de la signaturade la especificacion formal. Si fuera necesario, deberia 
actualizarse la especificacion informal en esta etapa. 

6. Definition de axiomas. Se define la semantica de las operaciones describiendo que 
condiciones son siempre verdaderas para diferentes combinaciones de operaciones. 

Para explicar la tecnica de especificacion algebraica, se utiliza un ejemplo de una estruc- 
tura de datos sencilla (una lista enlazada), tal y como se muestra en la Figura 10.7. Las listas 
enlazadas son estructuras de datos ordenados en donde cada elemento incluye un enlace al si- 
guiente elemento de la estructura. Se ha usado una lista sencilla con solamente unas pocas 
operaciones asociadas para que la exposicion no sea demasiado larga. En la practica, las cla- 
ses de objetos que definen una lista podrian tener probablemente mas operaciones. 

Supongamos que la primera etapa del proceso de especificacion, es decir, la estructura 
de la especificacion, se ha llevado a cabo y se ha identificado la necesidad de una lista. El 
nombre de la especificacion y el nombre de la clase pueden serel mismo, si bien esutil dis- 
tinguirentre estosusando algunaconvencion. Aqui se usan las mayusculas para el nombre 
de la especificacion (LIST) y minusculas con la inicial en mayusculas para el nombre de la 
clase (List). Como las listas son colecciones de otros tipos, la especificacion tiene un para- 
metro generico (Elem). El nombre Elem puede representar cualquier tipo: integer, string, 
list, y otros. 

En general, para cada tipo abstracto de datos, las operaciones requeridas deberian incluir 
una operacion para crear instancias de ese tipo (Create ) y para construir el tipo apartir de sus 
elementos basicos (Cons). En el caso de las listas, deberia haber una operacion para evaluar 
el primer elemento de la lista ( Head ), una operacion que devuelva la lista creada eliminando 
el primer elemento (Tail), y una operacion para contar el numero de elementos de la lista 
(Length). 
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LIST ( Elem ) 



sort List 

imports INTEGER 



Define una lista en donde los elementos se afiaden al final y se eliminan 
desde el principio. Las operaciones son Create, que crea una lista vacla; 
Cons, que crea una nueva lista con un elemento anadido; Length, que 
evaltia et tamafto de la lista; Head, que evaltia el primer elemento de la 
lista; y Tail, que crea una lista eliminando el primer elemento de su lista 
de entrada. Undefined represents un valor indefinido de tipo Elem. 



Create -• List 
Cons (List, Elem) -* List 
Head (List) -» Elem 
Length (List) -» Integer 
Tail (List) — List 



Head (Create) = Undefined exception (empty list) 

Head (Cons (L, v)) = if L = Create then v else Head (L) 

Length (Create) = 0 

Length (Cons (L, v)) = Lenglh (L) + 1 

Tail (Create ) = Create 

Tail (Cons (L, v)) = if L = Create then Create else Cons (Tail (L), 



v) 
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Para definir la sintaxis de cada una de estas operaciones, debe decidirse que parametros 
se requieren para cada operacion y los resultados de la operacion. En general, los parame- 
tros de entrada son tanto la clase que se esta definiendo (List) como la clase generica 
( Elem). Los resultados de las operaciones pueden ser objetos de esas clases o de alguna otra 
clase, como porejemplo Integer o Boolean. En el ejemplo de la lista, la operacion Length 
deberia devolverun entero. Por lo tanto, se debe incluirunadeclaracion «imports» decla- 
rando que la especificacion de un entero se utiliza en la especificacion de la lista. 

Para crear la especificacion, se define un conjunto de axiomas que se aplican al tipo abs- 
tracto y estos especifican su semantica. Se definen los axiomas que utilizan las operaciones 
definidas en la parte de la signatura. Estos axiomas especifican la semantica indicando lo que 
es siempre cierto acerca del comportamiento de las entidades de ese tipo abstracto. 

Las operaciones de un tipo abstracto de datos normalmente se clasifican en dos catego- 
rias: 

1 . Operaciones de construction (constructores), que crean o modifican las entidades de 
la clase definidas en la especificacion. Normalmente, estas operaciones reciben nom- 
bres como Create, Update, Add o, en este caso. Cons, que significa construir. 

2. Operaciones de inspection, que evaluan los atributos de la clase definidos en la espe- 
cificacion. Normalmente, estos tienen nombres como Eval o Get, 

Una buena regla para redactar una especificacion algebraica es establecer las operaciones 
de construccion y escribir un axioma para cada operacion de inspeccion sobre cada construc- 
tor. Esto sugiere que si hay m operaciones de construccion y n operaciones de inspeccion, de- 
fa erian definirse m * n axiomas. 

Sin embargo, las operaciones de construccion asociadas con un tipo abstracto pueden no 
ser siempre constructores primitivos. Esto es, pueden definirse usando otros constructores y 
operaciones de inspeccion. Si se define una operacion de construccion usando otros cons- 
tructores, entonces solamente se necesita definir las operaciones de inspeccion usando los 
constructores primitivos. 

En la especificacion de la lista, las operaciones de construccion que construyen las listas 
son Create, Cons y Tail. Las operaciones de inspeccion son Head (devuelve el valor del pri- 
mer elemento de la lista) y Length (devuelve el numero de elementos de la lista), los cuales 
se usan para descubrir atributos de la lista. LaoperacionTail, sin embargo, no es un constructor 
primitivo. Por lo tanto, no es necesario definir axiomas sobre la operacion Tail para las ope- 
raciones Head y Length, pero se tiene que definir Tail usando las operaciones de los cons- 
tructores primitivos. 

Evaluar el primer elemento de una lista vacia devuelve un valor indefinido. Las especifi- 
caciones de Head y Tail muestran que Head evalua el principio de la lista y Tail evalua la lis- 
ia de entrada sin su primer elemento. La especificacion de Head establece que el primer ele- 
mento de una lista creada mediante Cons es o bien el valor anadido a la lista (si la lista inicial 
esta vacia) o el mismo que el primer elemento de la lista de parametros inicial de la operacion 
Cons. Anadir un elemento a una lista no afecta a su primer elemento, amenos que la lista este 
vacia. 

Normalmente se usa recursividad cuando se redactan especificaciones algebraicas. El 
valor de la operacion Tail es la lista formada tomando la lista de entrada y eliminando su pri- 
mer elemento. La definicion de Tail muestra como la recursividad se usa en la construccion 
de especificaciones algebraicas. La operacion se define sobre listas vacias, y despues de ma- 
nera recursiva sobre listas no vacias, terminando la recursividad cuando se obtenga una lista 
vacia. 
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Algunas veces es mas facil comprender las especificaciones recursivas desarrollando un 
pequeno ejemplo. Supongamos que tenemos una lista [5, 7] en donde 5 es el primer elemen- 
to de la lista y 7 es el final de la lista. La operacion Cons ([5,7], 9) deberia devolver la lista 
[5, 7, 9] y la operacion Tail aplicada a esta deberia devolver la lista [7, 9]. La secuencia de 
ecuaciones resultantes de sustituir los parametros en la especificacion anterior con estos va- 
lores es: 

Tail ([5, 7, 9]) = 

Tail (Cons ( [5, 7], 9)) = Cons (Tail [5, 7]), 9) = 

Cons (Tail (Cons ([5], 7)), 9) = Cons (Cons (Tail ([5]), 7), 9) = 
Cons (Cons (Tail (Cons (Q, 5)), 7), 9) = Cons (Cons ([Create], 7), 9) = 
Cons ([7], 9) = [7, 9] 

La reescritura sistematica del axioma para Tail ilustra que realmente produce el resultado 
esperado. Se puede probar que el axioma para Head es correcto usando la misma tecnica de 
reescritura. 

Ahora vamos a mostrar como se puede usar la especificacion algebraica de una interfaz en 
una especificacion de un sistema critico. Supongase que, en un sistema de control de trafico 
aereo, se ha disefiado un objeto que representa un sector controlado del espacio aereo. Cada 
sector controlado puede incluir un numero de avion, cada uno de los cuales tiene un unico 
identificadorde avion. Porrazones de seguridad, todos los aviones deben separarse comomi- 
nimo 3 00 metros de altura. El sistema avisa al controlador si un avion intenta posicionarse de 
forma que incumpla esta restriccion. 

Para simplificar la descripcion, solamente se ha definido un numero limitado de operacio- 
nes sobre el objeto sector. En un sistema real, probablemente existan muchas mas operacio- 
nes y muchas mas condiciones de seguridad complejas relacionadas con la separacion hori- 
zontal del avion. Las operaciones criticas sobre el objeto son: 

1. Enter. Esta operacion anade un avion (representado por un Identificador) al espacio ae- 
reo a una altura especifica. No debe haber otro avion a esa altura o a menos de 300 me- 
tros de el. 

2. Leave. Esta operacion elimina el avion especificado del sector controlado. Esta ope- 
racion se usa cuando el avion se traslada a un sector adyacente. 

3. Move. Esta operacion mueve un avion de una altura a otra. De nuevo, debe com- 
probarse la restriccion de seguridad sobre la separacion vertical a menos de 300 me- 
tros. 

4. Lookup. Dado un Identificadorde avion, esta operacion devuelve la altura actual del 
avion en el sector. 

Es mas facil especificar estas operaciones si se definen algunas otras operaciones de la in- 
terfaz. Estas son: 

1. Create. Es una operacion estandar para un tipo abstracto de datos. Provoca que se 
cree una instancia vacia del tipo. En este caso, esta representa un sector que no tiene 
aviones. 

2. Put. Es una version mas simple de la operacion Enter. Anade un avion al sector sin 
chequearninguna restriccion asociada. 

3. In-space. Dada una serial de llamada de un avion, esta operacion de tipo logico de- 
vuelve cierto si el avion esta en el sector controlado, y falso en cualquier otro caso. 

4. Occupied. Dada una altura, esta operacion de tipo logico devuelve cierto si hay un 
avion a menos de 300 metros de esa altura, y falso en cualquier otro caso. 
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La ventaja de definir estas operaciones mas sencillas es que pueden entonces usarse como 
bloques de construccion para definir operaciones mas complejas sobre la clase Sector. La es- 
pecificacion algebraica de esta clase se muestra en la Figura 10.8. 

Fundamentalmente, las operaciones de construccion basicas son Create y Put, y aqui se 
usan en la especificacion de otras operaciones. Occupied e In-space son operaciones de com- 
probacion que se han definido utilizando Create y Put, y luego se usan en otras especifica- 



Flgura 10.8 

Especificacion de un 
sector controlado. 



-SECTOR 

sort Sector 

imports INTEGER, BOOLEAN 



Enter - aflade un avion al sector si se cumplen las condiciones de seguridad 

Leave - elimina un avi6n en el sector 

Move - mueve un avion de una altura a otra si es seguro hacerlo 

Lookup - encuentra la altura de un avion en el sector 

Create - crea un sector vado 

Put - anade un avi6n a un sector sin comprobaciones de restricciones 

In-space - comprueba si un avi6n ya esta en el sector 

Occupied - comprueba si esta disponible una altura especificada 



Enter (Sector, Call-sign, Height) -» Sector 
Leave (Sector, Call-sign) -* Sector 
Move (Sector, Call-sign, Height) -» Sector 
Lookup (Sector, Call-sign) — Height 

Create -» Sector 

Put (Sector, Call-sign, Height) — Sector 
ln-space (Sector, Call-sign) -* Boolean 
Occupied (Sector, Height) -» Boolean 



Enter (S, CS, H) = 
M In-space (S, CS ) then S exception (Aircraft already in sector) 
elsif Occupied (S, H) then S exception (Height conflict) 
else Put(S, CS, H) 

Leave (Create, CS) = Create exception (Aircraft not in sector) 
Leave (Put (S, CS1 , H1), CS) = 

if CS = CS1 then S else Put (Leave (S, CS), CS1 , H1) 

Move (S, CS, H) = 

If S = Create then Create exception (No aircraft in sector) 
elsif not In-space (S, CS) then S exception (Aircraft not in sector) 
elsif Occupied (S, H) then S exception (Height conflict) 
else Put (Leave (S, CS), CS, H) 

- NO-HEIGHT es una constante que indica que no se puede devolver una altura valida 

Lookup (Create, CS) = NO-HEIGHT exception (Aircraft not in sector) 
Lookup (Put (S, CS1 , H1), CS) = 

if CS = CS1 then H1 else Lookup (S, CS) 

Occupied (Create, H) = false 
Occupied (Put (S, CS1 , H1), H) = 

if (H1 > H and H1 - H s 300) or (H > H1 and H - H1 s 300) then true 
else Occupied (S, H) 

In-space (Create, CS) = false 
ln-space (Put (S, CS1, H1), CS ) = 
^ if CS = CS1 then true else In-space (S, CS) , 
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ciones. No se dispone de espacio para explicar aqui con detalle todas las operaciones pero se 
describendos de ellas (Oceupied y Move). Con esta informacion, usteddeberia sercapazde 
comprender las especificaciones del resto de las operaciones. 

1. La operacion Oceupied toma un sector como parametro que representa la altura y 
comprueba si no hay ningun avion que tenga asignada dicha altura. Su especificacion 
establece que: 

• En un sector vacio (uno que ha sido creado con la operacion Create), cada nivel esta 
vacante. La operacion devuelve falso independientemente del valor del parametro 
altura. 

• Enun sector no vacio (uno sobre el que se han hecho previamente operaciones Put), 
la operacion Oceupied comprueba si la altura especificada (parametro H) esta a me- 
nos de 300 metros de la altura del avion que foe anadido en ultimo lugar por una 
operacion Put. Siesasi, la altura ya esta ocupaday, por tanto, el valor de Oceupied 
es cierto. 

• Si el sector no esta ocupado, la operacion comprueba dicho sector de forma recur- 
siva. Se puede pensar que esta operacion se lleva a cabo sobre el ultimo avion ana- 
dido en el sector. Si la altura no esta dentro del rango de la altura de ese avion, la 
operacion entonces comprueba con el avion anterior que ha sido anadido en el sec- 
tor y asi sucesivamente. Eventualmente, si no existe ningun avion en el rango de la 
altura especificada, la comprobacion se lleva a cabo con un sector vacio y. por tan- 
to, devuelve falso. 

2. La operacion Move mueve un avion de un sector desde una altura a otra. Su especifi- 
cacion establece que: 

• Si una operacion Move se aplica sobre un espacio aereo vacio (el resultado de 
Create), el espacio aereo no cambia y se lanza una excepcion para indicar que el 
avion especificado no esta en el espacio aereo. 

• Enun sector no vacio, la operacion primero comprueba (utilizando In -space) si el 
avion dado esta en el sector. Si no, se lanza una excepcion. Si esta, la operacion 
comprueba que la altura especificada este disponible (utilizando Oceupied), lan- 
zando una excepcion si ya hay un avion a esa altura. 

• Si la altura especificada esta disponible, la operacion Move es equivalente a que el 
avion especificado deje el espacio aereo (por lo tanto, se usa la operacion Lea ve)y 
se anada al sector a la nueva altura. 

103 Especificacion del comportamiento 

Las sencillas tecnicas algebraicas descritas en la seccion anterior pueden usarse para descri- 
bir interfaces en las que las operaciones del objeto son independientes de su estado, Es de- 
cir, los resultados de aplicar una operacion no deberian depender de los resultados de ope- 
raciones anteriores. En caso de que estas condiciones no se cumplan, las tecnicas algebraicas 
pueden resultarengorrosas. Ademas, amedidaque estas aumentan sutamano, seobservaque 
las descripciones algebraicas del comportamiento del sistema se vuelven mas dificiles de en- 
tender. 

Una aproximacion alternativa a la especificacion formal que se esta utilizando cada vez 
mas en proyectos industriales es la especificacion basada en modelos. La especificacion ba- 
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sada en modelos es una aproximacion a la especificacion formal en la que la especificacion 
del sistema se expresa como un modelo de estados del sistema. Se pueden especificar las 
operaciones del sistema definiendo como estas afectan ai estado del modelo del sistema. 
La combinacion de estas especificaciones define el comportamiento del sistema en su to- 
talidad. 

Algunas notaciones maduras para desarrollar especificaciones basadas en modelos son 
VDM (Jones, 1980; Jones, 1986), B (Wordsworth, 1996) yZ (Hayes, 1987; Spivey, 1992). En 
este libro se usa Z. En Z, los sistemas se modelan usando conjuntos y relaciones entre con- 
juntos. Sin embargo, Z ha ampliado estos conceptos matematicos con construcciones que so- 
portan de forma especifica la especificacion del software. 

En una introduccion a la especificacion basada en modelos, solamente se puede propor- 
cionar un vistazo general de como se puede desarrollar una especificacion. Una descripcion 
completa de la notacion Z esta fuera de este capitulo. En su lugar, se presentan algunos pe- 
queiios ejemplos para ilustrar la tecnica e introducir la notacion a medida que se requiera. Una 
completa descripcion de la notacion Z se encuentra en libros de texto tales como los de Di- 
ller(Ponere/a/., 1996)yJacky (Jacky, 1997). 

Las especificaciones formales pueden ser dificiles y tediosas de leer, especialmente cuan- 
do se presentan como largas formulas matematicas. Los disenadores de Z han prestado una 
atencion particular a este problema. Las especificaciones se presentan como texto informal 
complementado con descripciones formales. La descripcion formal se incluye como peque- 
nos trozos faciles de leer (denominados esquemas) que se distinguen del texto asociado re- 
saltandolagraficamente. Los esquemas se usan para introducir variables de estado y para de- 
finir restricciones y operaciones sobre ese estado. Los esquemas pueden ser manipulados 
utilizando operaciones tales como composicion de esquemas, renombrado de esquemas y 
ocultacion de esquemas. 

Para ser mas efectiva, una especificacion formal debe complementarse con descripciones 
informales. La presentacion del esquema Z se ha disenado para que se destaque del texto que 
lo rodea (Figura 10.9). 

La signature del esquema define las entidades que forman el estado del sistema y el pre- 
dicado del esquema establece las condiciones que deberian cumplirse siempre para estas en- 
tidades. Cuando un esquema define una operacion, el predicado puede establecer precondi- 
ciones y postcondiciones. Estas definen el estado antes y despues de la operacion. La 
diferencia entre estas pre y postcondiciones define la accion especificada en el esquema de la 
operacion. 

Para ilustrar el uso de Z en la especificacion de un sistema critico, se ha desarrollado una 
X especificacion formal del sistema de control de la bomba de insulina que se introdujo en el 

Capitulo 3. 

Recuerde que este sistema moniloriza el nivel de glucosa en la sangre de los diabeticos y 
automaticamente inyecta la insulina necesaria. Incluso para un sistema pequeno como el de 



Figura 10.9 

La estructura 

de un esquema Z. 



Nombre 
del esquema 

/ 

■ Container — 
contents: M s 
capacity: M 



Signatura 
del esquema 



contents 'k capacity 



Predicado 
del esquema 
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la bomba de insulina, la especificacion formal es bastante larga. Si bien la operacion basica 
del sistema es sencilla, hay muchas condiciones de alarma posibles que tienen que serconsi- 
deradas. Aqui solamente se incluyen algunos de los esquemas que definen el sistema; la es- 
pecificacion completa puede descargarse del sitio web del libro. 

Para desarrollar una especificacion basada en modelos, se tienen que definir variables de 
estado y predicados que modelen el estado del sistema que se esta especificando, asi como 
definir invariantes (condiciones que son siempre ciertas) sobre esas variables de estado. 

El esquema de estados Z que modela el estado de la bomba de insulina se muestra en la F i - 
gura 10.10. Puede verse como se usan las dos partes basicas del esquema. En la parte supe- 
rior, se declaran los nombres y los tipos, y en la parte inferior, los invariantes. 

Los nombres declarados en el esquema se usan para representar entradas del sistema, sa- 
lidas del sistema y estados internos de las variables: 

1. Entradas del sistema para las que la convencion en Z es que todos los nombres de va- 
riables de entrada sean seguidos por el simbolo ?. Se han declarado nombres para mo- 
delar el interruptor encendido/apagado de la bomba (switch?), un boton para sumi- 
nistro manual de insulina (Manual Del ivery Button?), la lecturadel sensor de aziicaren 
la sangre (Reading?), el resultado de ejecutar un programa de prueba del hardware 
(HardwareTest?), sensores que detectan el deposito de insulina y la aguja( Insulin Re- 
servoir?, Needle?), y el valor del tiempo actual (dock?). 

2. Salidas del sistema para las que la convencion en Z es que todos los nombres de va- 
riables sean seguidos por el simbolo !. Se han declarado nombres para modelar la 
alarma de la bomba (alarm!), dos pantallas alfanumericas (display! 1 y display2!), 
una pantalla para el tiempo actual (clock!), y la dosis de insulina a suministrar 
(dosel). 

3 . Variables de estado usadas para el cdlculo de la dosis. Se han declarado variables 
para representar el estado del dispositivo (status) para almacenar valores previos del 
nivel de azucar en la sangre (rO. rl y r2), la capacidad del deposito de insulina y la 
capacidad de insulina actualmente disponible (capacity, insulin avaf iable) , varias 
variables usadas para limitar la dosis de insulina suministrada (max_daily_dose, 
max_single_dose, minimun_dose, safemin, safemax), y dos variables usadas en 
el calculo de la dosis (CompDose y cumulative_dose). El tipo N significa un nu- 
mero no negativo. 

El predicado del esquema define invariantes que son siempre ciertos. Aqui hay un «and» 
implicito entre cada linea del predicado, de forma que todos los predicados deben cumplirse 
durante todo el tiempo. Algunos de estos predicados simplemente fijan los limites del siste- 
ma, pero otros definen condiciones de funcionamiento fundamentales del sistema. Estas com- 
prenden las siguientes: 

1 . La dosis debe ser menor o igual que la capacidad del deposito de insulina. Es decir, es 
imposible suministrar mas insulina de la que hay en el deposito. 

2. La dosis acumulada se inicializa cada dia a media noche. Se puede considerar que la 
frase en Z <expresion logica 1 > => <expresion logica 2> significa lo mismo que si ex- 
presion logica 1> entonces <expresion logica 2>. En este caso, <expresion logica 1> 
es «clock?=")00000» y <expresion logica 2> es «cumulative_dose = 0», 

3. La dosis acumulada suministrada durante un periodo de 24 horas no puede superar 
max_daily_dose. Si esta condicion es falsa, entonces se muestra un mensaje de error. 

4. display2! siempre muestra el valor de la ultima dosis de insulina suministrada y dock! 
siempre muestra la hora actual. 
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INSULIN_PUMP3TATE 

// Definicidn de dispositivo de entrada 
switch?: (oft, manual, auto) 
ManualDeliveryButton?: ft 
Reading?: N 

HardwareTest?: (OK, batterylow, pumpfail, sensorfail, deliveryfail) 
InsulinReservoir?: (present, notpresent) 
Needle?: (present, notpresent) 
dock?: TIME 

//Definicidn de dispositivo de salida 

alarm! = (on, off) 

display 1 1 string 

display2!: string 

clock!: TIME 

dose!: N 

// Variables de estado usadas para el calculo de la dosis 
status: (running, warning, error) 
rO, M,r2:N 

capacity, insulin_available : N 

max_daily_dose, max_single_dose, minimum^dose: IN 

safemin, safemax: N 

CompDose, cumulative dose: N 



r2 = Reading? 

dose! s insulin_available 

irtsulin_availabie capacity 

//La dosis de insulina acumulada suministrada se inicializa a cero una vez cada 24 horas 
clock? = 000000 => cumulative_dose = 0 

//Si la dosis acumulada excede el limite entonces la operacidn se suspende 
cumulative_dose & max_daily_dose a status = error => 
display 1 ! = "Daily dose exceeded" 

// Pardmetros de configuracidn de la bomba 
capacity = 100 a safemin = 6 a safemax — 14 
max_daily_dose = 25 a max_single_dose = 4a minimum_dose = 1 



Flgura 10.10 

Esquema de estados 
para la bomba 
de insulina. 



display 2! = nat_to_string (dose!) 
clock! = clock? 
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La bomba de insulina funciona comprobando la glucosa en la sangre cada 10 minutos, y 
(de forma muy simple) la insulina se suministra si se incrementa la velocidad a la que cam- 
bia la glucosa en la sangre. El esquema que hemos denominado RUN, mostrado en la Figura 
10.1 1, modela la condicion de funcionamiento normal de la bomba. Si el nombre de un es- 
quema se incluye en la parte de declaraciones, esto es equivalente a incluir todos los nombres 
declarados en ese esquema en la declaracion y las condiciones en la parte de predicados. El 
esquema delta (A) en la primera linea de la Figura 10.11 ilustra esto. El simbolo delta signi- 
fica que las variables de estado definidas en INSULIN PUMP STATE pertenecen a su ambito 
en tanto que son un conjunto de variables que representan valores de estado antes y despues 
de lamisma operacion. Estos se indican afiadiendo unacomilla simple al nombre definido en 
INSULIN PUMP STATE. Por lo tanto, insulin_available representa lacantidadde insulina 



RUN 



AINSUUNJtfEMBPsgiSTE 



switch? = auto _ 

status - runmiing y status, = wanning 
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CompBose + cunuiative.dose < nutK_.daiy_dsse => 

( CompOose « ma* single dose => dasoi<= GannpOese 

V 



tmsulim avaikablaes maausiaqfojdose * 4 = 
display I = "Insulin ItW 



status' = wasn'm^/A 



Figura io.il 

El esquema RUN. 



rl' = r2 
r0' = rl 
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disponible antes de alguna operacion, e insulinavailable' representa la cantidad de insulina 
disponible despues de alguna operacion. 

El esquema RUN define el funcionamiento del sistema especificando un conjunto de 
predicados que son ciertos en el uso normal del sistema. Por supuesto, ademas de estos, 
estan los predicados definidos en el esquema INSULIN_PUMP_STATE que son invariantes 
(siempre ciertos). Este esquema tambien muestra el uso de una caracteristica del lenguaje Z 
— composicion de esquemas — en donde los esquemas SUGAR_L0W, SUGAR_0K, y 
SUGAR_HIGH se incluyen dando sus nombres. Tenga en cuenta que estos tres esquemas son 
«excluyentes» de forma que hay un esquema para cada una de las tres posibles condiciones. 
La capacidad para componer esquemas significa que se puede dividir una especificacion en 
partes mas pequenas de la misma forma que se pueden definir funciones y metodos en un pro- 
grama. 

Aqui no vamos a entraren detalles en el esquema RUN, pero, basicamente, comienza de- 
finiendo predicados que son ciertos en el funcionamiento normal. Por ejemplo, establece que 
el funcionamiento normal solamente es posible cuando la cantidad de insulina disponible es 
mayor que la dosis maxima unica que puede suministrarse. Tres esquemas que representan 
diferentes niveles de azucar en la sangre son por lo tanto excluyentes y, como veremos mas 
adelante, estos definen un valor para la variable de estado CompDose. 

El valor de Comp Dose representa la cantidad de insulina que ha sido calculada para su 
suministro, basada en el nivel de azucar en la sangre. El resto de los predicados en este es- 
quema definen varias comprobaciones que deben ser aplicadas para asegurar que la dosis re- 
almente suministrada (dose!) cumple las reglas de seguridad definidas para el sistema. Por 
ejemplo, una regla de seguridad es que ninguna dosis unica de insulina pueda sobrepasar un 
valor maximo definido. 

Finalmente, los dos ultimos predicados definen los cambios para el valor de insulin avai- 
lable y cumulative dose. Observe como se hausado aqui la version con comilla simple. 

El ultimo ejemplo de esquema dado en la Figura 10.12 define como se calcula la dosis de 
insulina asumiendo que el nivel de azucar en la sangre del diabetico se encuentra en una zona 

SU6AILQK - 

r2 ^ safemin v r2 A safemax 

r2 > safemin vrz A saremax 

// Nivel de azucar estabte g en descenso 
// Nivel ae azucar esfaoJe o en descenso 
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Figura 10.12 

El esquema 
SUGAR_0K. 



r2 > rl a (r2-rl) 2 (rl-rO) a (round ((r2-rl)/4) > 0) => 
CompDose = round ((r2-rl)/4) 
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de seguridad. En esas circunstancias, la insulina solamente se suministra si el nivel de azucar 
en la sangre crece y tambien se incrementa la velocidad de cambio de azucar en la sangre. 
El resto de los esquemas, SUGARJ-OW y SUGAR HIGH definen la dosis a suministrar si el 
nivel de azucar esta fuera de la zona de seguridad. Los predicados en el esquema son los 
siguientes: 

1. Elpredicado inicial define la zona de seguridad; es decir, r2 debe estar entre safemfn 
y safemax. 

2. Si el nivel de azucar es estable o decreciente, indicado por r2 (la ultima lectura) sien- 
do igual o menor que rl (una lectura anterior), entonces la dosis de insulina a sumi- 
nistrar es cero. 

3. Si el nivel de azucar es creciente (r2 mayor que rl) pero la velocidad de crecimiento 
es decreciente, entonces la dosis a suministrar es cero. 

4. Si el nivel de azucar es creciente y la velocidad de crecimiento es estable, entonces se 
suministra una dosis minima de insulina. 

5. Si el nivel de azucar es creciente y la velocidad de crecimiento es decreciente, enton- 
ces la velocidad de insulina a suministrar se calcula aplicando una sencilla formula a 
los valores calculados. 

No modelamos el comportamiento temporal del sistema (por ejemplo, el hecho de que el 
sensor de glucosa se comprueba cada 10 minutos) usando el lenguaje Z. Si bien es ciertamente 
posible, tambien es engorroso, y podriamos decir una descripcion informal realmente mues- 
tra la especificacion de forma mas concisa que una especificacion formal. 



PUNTOS CLAVE 

• Los me tod os de especificacion formal de sistemas complementan a las tecnicasde especificacion Informal de 
requerimientos. Pueden utilizarse con la definicion de requerimientos mediante lenguaje natural para clarlf I- 
car cualquier area de ambiguedad potencial en la especificacion. 

• Las especificaci ones form ales son precisas y no ambigu as. El iminan las a re as dud osas en una especificacion 
yevitan algunos de tos problemas de mala Interpretacion del lenguaje. Sin embargo, los no especialistas pue- 
den encontrar estas especificaciones formales dificiles de entender. 

• La ventaja fundamental de usar metodos formales en el proceso del software es que fuerza a un analisis de 
los requerimientos del sistema en una etapa Inicial. Corregir errores en esta etapa es menos costoso que mo- 
dificar un sistema ya entregado. 

• Las tecnicasde especificacion formal son mas rentablesen el desarrollo de sistemas criticos en los que la se- 
guridad, Habilidad y proteccion son particularmente importantes. Tambien pueden utilizarse para especificar 
estandares. 

• Lastecnicasalgebraicasde especificacion formal son especialmente adecuadas para especificar interfaces en 
donde la interfaz se define como un conjunto de clases de objetos o tipos abstractos de datos. Estas tecnicas 
ocultan el estado del sistema y especifican el sistema en f uncion de las relaciones entre las operaciones de la 
Interfaz. 
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• Las tecnicasbasadasenmodelosmodelanel sistema utilizando const ruccionesmatematicas tales co mo con- 
juntos y funciones. Estas pueden mostrar el estado del sistema, lo que simplifica algunos tipos de especifi- 
cacion del comportamiento. 

• Las operaciones se definen en una especificacion basada en modelos definiendo las precondiciones y post- 
condiciones sobre el estado del sistema. 



lecturas adici onales MBiw UMI IHmHMatfi 

«Correctness by construction: Developing a commercially secure system». Una buena descripcion de como pueden 
usarse los metodos formales en el desarrollo de un sistema de proteccion critico. [A. Hall y R. Chapman, IEEE Soft- 
ware, 19(1), enero 2002.] 

IEEE Transactions on Software Engineering, enero 1998. Este numero de la revista incluye una seccion especial so- 
bre usos practicos de los metodos formales en ingenieria del software. Incluye articulos del lenguaje Zy del lenguaje 
LARCH. 

«Formal methods: Promises and problems». Este articulo es un analisis realista de los beneficios potenciales del uso 
de metodos formales y de las dificultades de integrar el uso de estos metodos en el desarrollo practico del softwa- 
re. [Luqi y J. Goguen. lEEESoftware, 14(1), enero 1997.] 



10.1 Sugieraporque el diseno arquitectonico de un sistema deberia precederal desarrollo de una especifica- 
cion formal. 

102 Se le ha asignado la tarea de «vender» tecnicas de especificacion formal a una empresa de desarrollo de 
software. Indique como podria explicar las ventajas de las especificaciones formales a ingenieros de soft- 
ware escepticos y practicos. 

103 Explique por que es particularmente importante definir las interfaces de los subsistemas de forma preci- 
sa y por que la especificacion algebraica es particularmente adecuada para la especificacion de estas in- 
terfaces. 

104 Un tipo abstracto de datos que representa una pila tiene las siguientes operaciones asociadas: 
New: Crea una pila. 

Push: Anade un elemento en la cima de la pila. 
Top: Obtiene el elemento de la cima de la pila. 

Retract: Elimina el elemento de la cima de la pila y devuelve la pila modificada. 
Empty: Cierto si no hay elementos en la pila. 

Defina este tipo abstracto de datos utilizando una especificacion algebraica. 
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10.5 En el ejemplo de un sector controlado del espacio aereo, la condicion de seguridad es que no debe estar 
dentro de los 300 m de altura en el mismo sector. Modifique la especificacion mostrada en la Figura 10.8 
para permitir que el avion ocupe la misma altura en el sector si esta separado al menos 8 km horizontal- 
mente. Usted puede prescindirde los aviones en los sectores adyacentes. Sugerencia: tiene que modifi- 
car las operaciones de construccion para que incluyan la posicion del avion asi como su altura. Tambien 
tiene que definiruna operacion que, dadas dos posiciones, devuelva la separacion entre ellas. 

10.6 Los cajeros automaticos de los bancos utilizan la informacion de las tarjetas de los usuarios mediante el 
identificador del banco, el numero de cuenta y el identificador personal del usuario. Tambien generan in- 
formacion de la cuenta a partir de una base de datos central y actualizan dicha base de datos al comple- 
tar la transaccion. Empleando su conocimiento del funcionamiento de un ATM, escriba esquemas Z que de- 
finan el estado del sistema, lavalidacion de latarjeta (en la que se comprueba la identificacion del usuario) 
y la retirada de efectivo. 

10.7 Modifique el esquema de bomba de insulina, mostrado en la Figura 10.10, y afiada una condicion de se- 
guridad adicional de forma que el ManualDeliveryButton? pueda tener solamente un valor distinto de cero 
si el interrupter de la bomba esta en la posicion manual. 

10.8 Escriba un esquema Z denominado SELF TEST que compruebe los componentes hardware de la bomba de 
insulina y fije los valores de la variable de estado HarwareTest?. A continuacion modifique el esquema RUN 
para comprobar que el hardware funciona correctamente antes de que se suministre insulina. Si no, la do- 
sis suministrada deberia ser cero y se deberia mostrarse un error en la pantalla de la bomba de insulina. 

10.9 Z soporta la nocion de sucesiones en donde una sucesion escomo un vector. Por ejemplo, para una suce- 
sion S, usted puede referirse a sus elementos como S[i], S[2], y asi sucesivamente. Tambien lepermitede- 
terminarel numero de elementos de una sucesion usando el operador #. Es decir, si una sucesion S es [a, 
b, c, d], entonces #S es 4. Usted puede afiadir un elemento al final de una sucesion S escribiendo S + a, y 
al principio de la secuencia escribiendo a + S. Usando estas construcciones, escriba una especificacion Z 
de la LIST que se especifica algebraicamente en la Figura 10.7. 

Usted es un ingeniero de sistemas y se le pide que sugiera la mejor manera para desarrollar el software 
de un sistema de seguridad critico para un marcapasos del corazon. Usted sugiere especificar formalmente 
el sistema, pero su gestor rechaza su sugerencia. Usted piensa que sus razones son debiles y basadas en 
prejuicios. ^Es etico desarrollar el sistema usando metodos que usted piensa que son inadecuados? 
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Capftulo 11 Diseno arquitectonico 

Capftulo 12 Arquitecturas de sistemas distribuidos 

Capftulo 13 Arquitecturas de aplicaciones 

Capftulo 14 Diseno orientado a objetos 

Capftulo 15 Diseno de software de tiempo real 

Capitulo 16 Diseno de interfaces de usuario 



La esencia del diseho del software es la toma de decisiones sobre la organizacion Idgi- 
ca del software. Algunas veces, listed representa esta organizacion logica como un mo- 
delo en un lenguaje definido de modelado tal como UML y otras veces usted simple- 
mente utiliza notaciones informales y esbozos para representar el diseho. Por supuesto, 
usted raramente empieza desde cero cuandotoma decisiones sobre la organizacion del 
software sino que basa su diseho sobre experiencias de diseho anteriores. 

Algunos autores piensan que la mejor forma de encapsular esta experiencia de dise- 
ho es mediante metodos estructurados en donde usted sigue un proceso definido de 
disehoy describe su diseho utilizando diferentestipos de modelos. Yo nunca he sido un 
gran seguidor de los metodos estructurados ya que siempre he pensado que son de- 
nt asi ado restrictivos. El diseho es un proceso creativo yyocreofirmemente que cada uno 
de nosotros abordamos dicho proceso creativo de forma particular. No hay una forma 
buena o mala de disehar el software y ni yo ni nadie puede darle una 'formula' para el 
d i se ho del software. Usted aprende como disehar observando ejemplosdedisehosexis- 
tentes y discutiendo su diseho con otros. 

En lugarde representar la experiencia como un «metodo de diseho », yo pref iero una 
aproximacion menosestructurada. Los c a pit u I os de esta parte encapsulanconocimien- 
to sobre estructuras de software que ban sido utilizadas con exito en otros sistemas, pre- 
sentan algunos ejemplos y le proporcionan algun consejo sobre procesos de diseho: 

1. Los Ca pit u I os del 11 al 13 hablan sobre las estructuras abstractas del software. El 
Capitulo 11 discute perspectivas estructurales que se han encontrado utiles para 
el diseho del software, el Capitulo 12 habla sobre como estructurar el software 
para su ejecucion distribuida y el Capitulo 13 habla sobre estructuras genericas 
para varios tipos de aplicaciones. El Capitulo 13 es nuevo y lo he incluido en esta 
edicion debido a que he visto que muchos estudiantes de ingenieria del software 
no tienen experiencia en software de aplicaciones a parte de los sistemas inter- 
activos que ellos usan de forma cotidiana en sus propios ordenadores. 

2. Los C a p it u I os del 14 al 16 abordan cuestiones de d i seho del software m a s espe- 
cificas. El Capitulo 14, que cubre el diseho orientado a objetos, trata una forma 
de pensar sobre las estructuras del software. El Capitulo 15, dedicado al diseho 
de sistemas de tiempo real, discute las estructuras del software que usted nece- 
sita en sistemas en los que una respuesta a tiempo es un requerimiento critico. 
El Capitulo 16 es un poco diferente debido a que esta centrado en el diseho de 
la interfaz de usuario en vez de estructuras del software. Como ingeniero, usted 
tiene que pensar sobre los sistemas —no solamente sobre el software— y las 
personas del sistema son un componente esencial. El diseho no termina con la 
definicion de las estructuras del software sino que continua con como se usa el 
software. 
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Objetivos 

El objetivo de este capitulo es introducir los conceptos de la 
arquitectura del software y del diseno arquitectonico. Cuando haya 
leido este capitulo: 

• comprendera por que es importante el diseno arquitectonico 
del software; 

• comprendera las decisiones que tienen que tomarse sobre la 
arquitectura del sistema durante el proceso de diseno 
arquitectonico; 

• habra sido introducido en tres estilos arquitectonicos 
complementarios que abarcan la organizacion del sistema en 
su totalidad, la descomposicion modular y el control; 

• comprendera como se utilizan las arquitecturas de referencia 
para comunicar conceptos arquitectonicos y para evaluar las 
arquitecturas de los sistemas. 

Contenidos 

11.1 Decisiones de diseno arquitectonico 

11.2 Organizacion del sistema 

11.5 Estilos de descomposicion modular 

11.4 Estilos de control 

11.5 Arquitecturas de referencia 
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Los grandes sistemas siempre se descomponen en subsistemas que proporcionan algun con- 
junto de servicios relacionados. El proceso de diseno inicial que identifica estos subsistemas 
y establece un marco para el control y comunicacion de los subsistemas se llama diseno ar- 
quitectonico. El resultadode este proceso de diseno es unadescripcion de la arquitectura del 
software. 

En el modelo presentado en el Capitulo 4, el diseno arquitectonico es la primera etapa en 
el proceso de diseno y representa un enlace critico entre los procesos de ingenieria de diseno 
y de requerimientos. El proceso de diseno arquitectonico esta relacionado con el estableci- 
miento de un marco estructural basico que identifica los principales componentes de un sis- 
tema y las comunicaciones entre estos componentes. 

Bass y otros (Bass et a/., 2003) sefialan tres ventajas de disenar explicitamente y docu- 
mentar la arquitectura del software: 

1. Comunicacion con los stakeholders. La arquitectura constituye una presentacion de 
alto nivel del sistema que puede usarse como punto de discusion por varios stakehol- 
ders. 

2. Andlisis del sistema. Hacer expllcita la arquitectura del sistema en una etapa tempra- 
na del desarrollo del sistema requiere realizar algun analisis. Las decisiones de dise- 
no arquitectonico tienen un gran efecto sobre si el sistema puede cumplir los requeri- 
mientos criticos (ales como rendimiento, fiabilidady mantenibilidad. 

3. Reutilizacidn a gran escala. Un modelo de arquitectura del sistema es una descripcion 
compacta y manejable de como se organiza un sistema y como interoperan sus com- 
ponentes. La arquitectura del sistema es a menudo la misma para sistemas con reque- 
rimientos similares y, por lo tanto, pueden soportar reutilizacidn del software a gran 
escala. Tal y como se indicaen el Capitulo 18, es posible desarrollar arquitecturas para 
lineas de productos en donde la misma arquitectura se usa en varios sistemas relacio- 
nados. 

Hofmeister y otros (Hofmeister et ah, 2000) ponen de manifiesto como las etapas del di- 
seno arquitectonico fuerzan a los disefladores del software a considerar aspectos de diseno cla- 
ves en etapas tempranas del proceso. Sugieren que la arquitectura del software puede servir 
como un plan de diseno que se usa para negociar los requerimientos del sistema y como una 
forma de estructurar las discusiones con los clientes, desarrolladores y gestores. Tambien su- 
gieren que es una herramienta esencial para la gestion de la complejidad. La arquitectura del 
software oculta detalles y permite a los disefladores centrarse en las abstracciones clave del 
sistema. 

La arquitectura del sistema afecta al rendimiento, solidez, grado de distribucion y mante- 
nibilidad de un sistema (Bosch, 2000). El estilo y estructura particulares elegidos para una 
aplicacion puede, por lo tanto, depender de los requerimientos no funcionales del sistema: 

1 . Rendimiento. Si el rendimiento es un requerimiento critico, la arquitectura deberia di- 
seflarse para identificar las operaciones criticas en un pequeflo numero de subsistemas, 
con tan poca comunicacion como sea posible entre estos subsistemas. Esto puede sig- 
nificar el uso relativo de componentes de grano grueso en vez de componentes de gra- 
no fino para reducir las comunicaciones entre ellos. 

2. Proteccion. Si la proteccion es un requerimiento critico, deberia usarse una arquitec- 
tura estructurada en capas, con los recursos mas criticos protegidos en las capas mas 
internas y aplicando una validacion de seguridad de alto nivel en dichas capas. 

3. Seguridad. Si la seguridad es un requerimiento critico, la arquitectura deberia dise- 
flarse para que las operaciones relacionadas con la seguridad se localizaran en un uni- 
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co subsistema o en un pequeno numero de subsistemas. Esto reduce los costes y los 
problemas de validacion de seguridad y hace posible crear los sistemas de proteccion 
relacionados con los de seguridad. 

4. Disponibilidad. Si la disponibilidad es un requerimiento critico, la arquitectura de- 
beria disefiarse para incluir componentes redundantes y para que sea posible reem- 
plazar y actualizar componentes sin detener el sistema. Las arquitecturas de siste- 
mas tolerantes a defectos para sistemas de alta disponibilidad se tratan en el 
Capitulo 20. 

5. Mantenibilidad. Si la mantenibilidad es un requerimiento critico, la arquitectura del 
sistema deberia disefiarse usando componentes independientes de grano fino que pue- 
dan modificarse con facilidad. Los productores de los datos deberian separarse de los 
consumidores y deberian evitarse las estructuras de datos compartidas. 

Obviamente, existe un conflicto potencial entre algunas de estas arquitecturas. Por ejem- 
plo, el uso de componentes de grano grueso mejora el rendimiento, y el uso de componentes 
de grano fino mejora la mantenibilidad. Si ambas propiedades son requerimientos importan- 
tes del sistema, entonces deberia encontrarse una solucion intermedia. Tal y como se indica 
mas adelante, esto puede conseguirse en ocasiones usando diferentes estilos arquitectonicos 
para diferentes partes del sistema. 

Hay un solape significativo entre los procesos de ingenieria de requerimientos y del dise- 
no arquitectonico. Idealmente, una especificacion del sistema no deberia incluir ninguna in- 
formacion de diseno. En lapractica, esto no es realistaexceptoparasistemasmuypequenos. 
La descomposicion arquitectonica es necesaria para estructurar y organizar la especificacion. 
Un ejemplo de esto se introdujo en el Capitulo 2. en donde la Figura 2.8 muestra la arquitec- 
tura de un sistema de control de trafico aereo. Puede usarse dicho modelo arquitectonico como 
punto de partidapara la especificacion de subsistemas. 

Un diseno de un subsistema es una descomposicion abstracta de un sistema en compo- 
nentes de grano grueso, cada uno de los cuales puede ser un sistema importante por si mis- 
mo. Los diagramas de bloques se usan a menudo para describir disenos de subsistemas en 
donde cada caja en el diagrama representa un subsistema. Cajas dentro de otras cajas indican 
que el subsistema se ha descompuesto a su vez en otros subsistemas. Las flechas significan 
que los datos o senales de control pasan de un subsistema a otro subsistema en la direccion 
de las flechas. Los diagramas de bloques presentan un dibujo de alto nivel de la estructura del 
sistema, la cual puede entenderse con facilidad por personas de diferentes disciplinas que es- 
tan implicadas en el proceso de desarrollo del sistema. 

Por ejemplo, la Figura 11.1 es un modelo abstracto de arquitectura para un sistema robo- 
tico para empaquetar que muestra los subsistemas que tienen que desarrollarse. Este sistema 
robotico puede empaquetar diferentes clases de objetos. Utiliza un subsistema de vision para 
tomar los objetos de una cinta transportadora, identificar el objeto y seleccionar el tipo de em- 
paquetado adecuado. A continuacion, el sistema mueve los objetos desde la cinta transporta- 
dora para ser empaquetados. El sistema coloca los objetos empaquetados en otra cinta trans- 
portadora. Otros ejemplos de diseno arquitectonico a este nivel se muestran en el Capitulo 2 
(Figuras 2.6 y 2.8). 

Bass y otros (Bass et ah. 2003) senalan que los diagramas sencillos de cajas y lineas no 
son representaciones arquitectonicas utiles debido a que no muestran la naturaleza de las re- 
laciones entre los componentes de! sistema ni tampoco las propiedades externamente visibles 
de los componentes. Desde la perspectiva de un disefiador de software, esto es absolutamen- 
te correcto. Sin embargo, este tipo de modelo es efectivo para la comunicacion con los stake- 
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holders del sistema y para la planificacion del proyecto debido a que no muestra los detalles. 
Los stakeholders pueden relacionarlo con el sistema y tener una vision abstracta del mismo. 
El modelo identifica los subsistemas clave que tienen que ser desarrollados de forma inde- 
pendiente para que los gestores puedan comenzar a asignar personas para planificar el des- 
arrollo de estos sistemas. Losdiagramas de cajasy lineas, desde luego, nodeberianserlauni- 
ca representacion arquitectonica usada; sin embargo, constituyen un modelo mas de entre los 
modelos arquitectonicos que pueden resultar utiles. 

El problema general de decidir como descomponer un sistema en subsistemas es dificil. 
Por supuesto, los requerimientos del sistema son un factor fundamental, y deberia intentarse 
crearun diseno en el que hubiera una clara correspondencia entre los requerimientos y los sub- 
sistemas. Esto significa que, si los requerimientos cambian, este cambio probablemente este 
localizado en un unico sitio en vez de distribuido entre varios subsistemas. En el Capitulo 1 3, 
se describen varias arquitecturas de aplicaciones genericas que pueden usarse como punto de 
partida para la identificacion de subsistemas. 



11.1 Decisiones de diseno arquitectonico 



El diseno arquitectonico es un proceso creativo en el que se intenta establecer una organi- 
zacion del sistema que satisfaga los requerimientos funcionales y no funcionales del pro- 
pio sistema. Debido a que es un proceso creativo, las actividades dentro del proceso difie- 
ren radicalmente dependiendo del tipo de sistema a desarrollar, el conocimiento y la 
experiencia del arquitecto del sistema, y los requerimientos especificos del mismo. Es, por 
tanto, mas util pensar en el proceso de diseno arquitectonico desde una perspectiva de de- 
cision en lugar de una perspectiva de actividades. Durante el proceso de diseno arquitec- 
tonico, los arquitectos del sistema tienen que tomar varias decisiones fundamentales que 
afectan profundamente al sistema y a su proceso de desarrollo. Basandose en su conoci- 
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miento y experiencia, los arquitectos del sistema tienen que responder a las siguientes 
cuestiones fundamentales: 

1 . ^Existe una arquitectura de aplicacion generica que pueda actuar como una plantilla 
para el sistema que se estan disefiando? 

2. ^Como se distribuira el sistema entre varios procesadores? 

3. iQue estilo o estilos arquitectonicos son apropiados para el sistema? 

4. ^Cual sera la aproximacion fundamental utilizada para estructurar el sistema? 

5. iComo se descompondran en modulos lasunidades estructurales del sistema? 

6. iQue estrategia se usara para controlar el funcionamiento de las unidades del sistema? 

7. ^Corno se evaluara el diseno arquitectonico? 

8. iComo deberia documentarse la arquitectura del sistema? 

Si bien cada sistema software es unico, los sistemas en el mismo dominio de aplicacion a 
menudo tienen arquitecturas similares que reflejan los conceptos fundamentales del dominio. 
Estas arquitecturas de las aplicaciones pueden serbastante genericas, tales como la arquitectu- 
ra de los sistemas de gestion de informacion, o pueden ser mucho mas especificas. Por ejem- 
plo, las aplicaciones de lineas de productos son aplicaciones construidas sobre una arquitectu- 
ra base con variantes que satisfacen los requerimientos especificos del cliente. Cuando se disefla 
la arquitectura de un sistema, se debe decidir que tiene en comun ese sistema con clases de apli- 
caciones mas amplias, y determinar en que medida el conocimiento de esas arquitecturas de 
aplicaciones se puede reutilizar. Las arquitecturas de las aplicaciones genericas se estudian en 
el Capitulo 13, y en el Capitulo 18 se analizan las aplicaciones de lineas de productos. 

Para sistemas embebidos y sistemas disefiados para computadoras personales, se utiliza 
normalmente un unico procesador, y no sera preciso disefiar una arquitectura distribuida para 
el sistema. Sin embargo, la mayoria de los sistemas grandes son actualmente sistemas distri- 
buidos en los que el software del sistema se distribuye entre muchas computadoras diferen- 
tes. La eleccion de la arquitectura de distribucion es una decision clave que afecta al rendi- 
miento y la Habilidad del sistema. Esta es una cuestion fundamental en si misma, y este tema 
se trata por separado en el Capitulo 12. 

La arquitectura de un sistema software puede basarse en un modelo o estilo arquitectoni- 
co particular. Un estilo arquitectonico es un patron de organizacion de un sistema (Garlan y 
Shaw, 1993) tal como una organizacion cliente-servidor o una arquitectura por capas. Es im- 
portante un conocimiento de estos estilos, sus aplicaciones, y sus ventajas e inconvenientes. 
Sin embargo, las arquitecturas de la mayoria de los sistemas grandes no utilizan un unico es- 
tilo. Pueden disenarse diferentes partes del sistema utilizando distintos estilos arquitectonicos. 
En algunos casos, la totalidad de la arquitectura del sistema puede ser una arquitectura com- 
puesta creada mediante la combinacion de diferentes estilos arquitectonicos. 

La nocion de Garlan y Shaw de un estilo arquitectonico incluye las tres siguientes cues- 
tiones de diseno. Se debe elegir la estructura mas adecuada, tal como una estructura cliente- 
servidor o por capas, que permita satisfacer los requerimientos del sistema. Para descompo- 
ner las unidades del sistema estructural en modulos, hay que decidir la estrategia para 
descomponer subsistemas en sus componentes o modulos. Las aproximaciones que pueden 
usarse permiten implementar diferentes tipos de arquitecturas. Finalmente, en el proceso de 
modelado de control, se toman decisiones sobre como se controla la ejecucion de los subsis- 
temas. Se desarrolla un modelo general de las relaciones de control entre las partes estableci- 
das del sistema. Estos tres temas se tratan en las Secciones de la 11.2 hasta la 11.4. 

La evaluacion de un diseno arquitectonico es dificil debido a que la verdadera prueba de 
una arquitectura consiste en averiguar el grado de satisfaccion de sus requerimientos funcio- 
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nales y no funcionales despues de que aquel ha sido desarrollado. Sin embargo, en algunos 
casos, se puede realizar alguna evaluacion comparando el diseno elaborado con modelos ar- 
quitectonicos genericos o de referencia. Las arquitecturas de referencia se tratan en la Seccion 
1 1 .5, y otras arquitecturas genericas, en el Capitulo 13. 

El resultado del proceso de diseno arquitectonico es un documento de diseno arquitecto- 
nico. Este puede incluirvarias representaciones graficas del sistemajuntocontextodescrip- 
tivo asociado. Deberia describircomo se estructura el sistemaen subsistemas, laaproxima- 
cion adoptada y como se estructura cada subsistema en modulos. Los modelos graficos del 
sistema presentan diferentes perspectivas de la arquitectura. Los modelos arquitectonicos que 
pueden desarrollarse pueden incluir: 

1. Un modelo estructural estdtico que muestre los subsistemas o componentes que han 
sido desarrollados como unidades separadas. 

2. Un modelo deproceso dindmico que muestre como se organiza el sistema en proce- 
sos en tiempo de ej ecucion. Este modelo puede ser diferente del modelo estatico. 

3. Un modelo de interfaz que defina los servicios ofrecidos por cada subsistema a traves 
de su interfaz publica. 

4. Modelos de relaciones que muestren las relaciones, tales como el flujo de datos, entre 
los subsistemas. 

5. Un modelo de distribution, que muestre como se distribuyen los subsistemas entre las 
computadoras. 

Varios investigadores han propuesto el uso de lenguajes de descripcion de arquitecturas 
(ADLs) para describir las arquitecturas de los sistemas. Bass y otros (Bass etal., 2003) des- 
criben las principales caracteristicas de estos lenguajes. Los elementos basicos de los ADLs 
son componentes y conectores, e incluyen reglas y recomendaciones para arquitecturas bien 
formadas. Sin embargo, como todos los lenguajes especializados, los ADLs solamente pue- 
den ser comprendidos por expertos del lenguaje y son inaccesibles para los especialistas tan- 
to de las aplicaciones como del dominio. Esto hace que sea dificil analizarlos desde una pers- 
pectiva practica. Presumiblemente, solo se usaran en unas pocas aplicaciones. Los modelos 
informales y las notaciones tales como U M L (Clements, etal., 2002) seran las notaciones mas 
comunmente usadas para la descripcion arquitectonica. 

11.2 Organizacion del sistema 

La organizacion de un sistema refleja la estrategia basica usada para estructurar dicho siste- 
ma. Deben tomarse decisiones sobre la totalidad del modelo organizacional de un sistema al 
principio del proceso de diseno arquitectonico. La organizacion del sistema puede reflejarse 
directamente en la estructura de los subsistemas. Sin embargo, es frecuente que el modelo de 
subsistemas incluya mas detalle que el organizacional, y no siempre hay una corresponden- 
cia sencilla desde los subsistemas a la estructura organizacional. 

En esta seccion, se incluyen tres estilos organizacionales ampliamente usados: un esti- 
lo de repositorio de datos, un estilo de servicios y servidores compartidos y una maquina 
abstracta o estilo por capas en donde el sistema se organiza en un conjunto de capas fun- 
cionales. Estos estilos se pueden utilizar juntos o por separado. Por ejemplo, un sistema 
puede organizarse alrededor de un repositorio de datos compartidos pero puede tambien 
construir capas alrededor de dicho repositorio para presentar una vision mas abstracta de 
los datos. 
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11.2.1 □ modelo de reposltorlo 

Los subsistemas que forman un sistema deben intercambiar informacion para que puedan tra- 
bajar conjuntamente de forma efectiva. Esto es puede conseguirde dos formas fundamentales: 

1 . Todos los datos compartidos se almacenan en una base de datos central a la que pue- 
de acceder por todos los subsistemas. Un modelo de sistema basado en una base de 
datos compartida se denomina algunas veces modelo de repositorio. 

2. Cada subsistema mantiene su propia base de datos. Los datos se intercambian con 
otros subsistemas mediante el paso de mensajes entre ellos. 

La mayoria de los sistemas que usan grandes cantidades de datos se organizan alrededor 
de una base de datos compartida o repositorio. Por lo tanto, este modelo es adecuado para apli- 
caciones en las que los datos son generados por un subsistema y son usados por otro. Ejem- 
plos de este tipo de sistemas se pueden citar los sistemas de mando y control, los sistemas de 
gestion de informacion, los sistemas CAD y los conjuntos de herramientas CASE. 

La Figura 11.2 es un ejemplo de una arquitectura de herramientas CASE basada en un re- 
positorio compartido. El primer repositorio compartido para herramientas C A S E se desarro- 
116 probablemente aprincipios de los 70 porunacompania inglesadenominadalCLpara so- 
portarel desarrollo de su sistema operativo (McGuffin etal., 1979). Este modelo llego a ser 
ampliamente conocido cuando Buxton (Buxton. 1980) hizo las propuestas para el entorno Sto- 
neman como soporte para el desarrollo de sistemas escritos en Ada. Desde entonces, muchos 
de los conjuntos de herramientas C A S E se han desarrollado alrededor de un repositorio com- 
partido. 

Las ventajas y desventajas de un repositorio compartido son las siguientes: 

1. Es una forma eficiente de compartir grandes cantidades de datos. No hay necesidad de 
transmitirdatosexplicitamentede un subsistema a otro. 

2. Sin embargo, los subsistemas deben estaracordes con el modelo de datos del reposi- 
torio. Inevitablemente, hay un compromiso entre las necesidades especificas de cada 
herramienta. El rendimiento puede verse afectado de forma adversa por este compro- 
miso. Puede ser dificil o imposible integrar nuevos subsistemas si sus modelos de da- 
tos no se ajustan al esquema acordado. 

3. Los subsistemas que producen datos no necesitan conocer como se utilizan sus datos 
por otros subsistemas. 

4. Sin embargo, la evolucion puede ser dificil a medida que se genera un gran volumen 
de informacion de acuerdo con el modelo de dalos establecido. Traducir esto aun nue- 
vo modelo, desde luego, tendra un coste elevado; puede ser dificil o incluso imposible. 
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5. Las actividades tales como copias de seguridad, proteccion, control de acceso y recu- 
peracion de errores estan central izadas. Son las responsables de gestionar el reposito- 
rio. Las herramientas pueden centrarse en su funcion principal en lugar de estar rela- 
cionadas con estas cuestiones. 

6. Sin embargo, diferentes subsistemas pueden tener distintos requerimientos de protec- 
cion, recuperacion y politicas de seguridad. El modelo de repositorio impone la mis- 
ma politica para todos los subsistemas. 

7. El modelo de comparticion es visible a traves del esquema del repositorio. Las nuevas 
herramientas se integran de forma directa puesto que estas son compatibles con el mo- 
delo dc datos acordado. 

8. Sin embargo, puede serdificil distribuir el repositorio sobre varias maquinas. Si bien 
es posible un repositorio centralizado logicamente, puede haber problemas con la re- 
dundancia de datos y las inconsistencias. 

En el modelo anterior, el repositorio es pasivo y el control es responsabilidad de los sub- 
sistemas que utilizan el repositorio. Una aproximacion alternativa se deriva de los sistemas de 
AI (Inteligencia Artificial) que usan un modelo de pizarra (blackboard), el cual activa a los 
subsistemas cuando estan disponibles ciertos datos. Esto es adecuado cuando el repositorio 
de datos estapoco estructurado. Las decisiones sobre que herramienta se tiene que activar solo 
puede realizarse cuando los datos han sido analizados. Este modelo ha sido descrito por Nii 
(Nii, 1986) y Bosch (Bosch, 2000) e incluye unabuenademostracion sobre como este estilo 
se relaciona con los atributos de calidad del sistema. 

11.2.2 El modelo cllente-servldor 

El modelo arquitectonico cliente-servidor es un modelo de sistema en el que dicho sistema se 
organiza como un conjunto de servicios y servidores asociados, mas unos clientes que acce- 
den y usan los servicios. Los principales componentes de este modelo son: 

1. Un conjunto de servidores que ofrecen servicios a otros subsistemas. Ejemplos de ser- 
vidores son servidores de impresoras que ofrecen servicios de impresion, servidores 
de ficheros que ofrecen servicios de gestion de ficheros y servidores de compilacion, 
que ofrecen servicios de compilacion de lenguajes de programacion. 

2. Un conjunto de clientes que llaman a los servicios ofrecidos por los servidores. Estos 
son normalmente subsistemas en si mismos. Puede haber varias instancias de un pro- 
grama cliente ejecutandose concurrentemente. 

3. Una red que permite a los clientes acceder a estos servicios. Esto no es estrictamente 
necesario ya que los clientes y los servidores podrian ejecutarse sobre una unica ma- 
quina. En lapractica, sin embargo, la mayoriade los sistemas cliente-servidor se im- 
plementan como sistemas distribuidos. 

Los clientes pueden conocer los nombres de los servidores disponibles y los servicios que 
estos proporcionan. Sin embargo, los servidores no necesitan conocer la identidad de los clien- 
tes o cuantos clientes tienen. Los clientes acceden a los servicios proporcionados por un ser- 
vidor a traves de llamadas a procedimientos remotos usando un protocolo de peticion-res- 
puesta tal como el protocolo http usado en la WWW. Basicamente, un cliente realiza una 
peticion a un servidor y espera hasta que recibe una respuesta. 

La Figura 11.3 muestra un ejemplo de un sistema basado en el modelo cliente-servidor. 
Este es un sistema multiusuario basado en web para proporcionar una biblioteca de peliculas 
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y fotografias. En este sistema, varios servidores gestionany visualizan diferentes tipos de dis- 
positivos. Las secuencias de video necesitan ser transmitidas rapidamente y en sincronia, pero 
con una resolucion relativamente baja. Estas pueden comprimirse en un almacen para que el 
servidor de video pueda gestionar la compresion y descompresion de video en diferentes for- 
mates. Sin embargo, las fotografias deben mantenerse con una alta resolucion, por lo que es 
adecuado mantenerlas en un servidor separado. 

El catalogo debe ser capaz de manejar una gran variedad de peticiones y proporcionar en- 
laces al sistema de informacion web que incluye datos sobre las peliculas de video y fotogra- 
fias y un sistema de comercio electronico que soporta la venta de peliculas de video y foto- 
grafias. El programa cliente es simplemente una interfaz de usuario integrada con estos 
servicios y construida usando un navegador web. 

La ventaja mas importante del modelo cliente-servidor es que es una arquitectura distri- 
buida. Se puede hacer un uso efectivo de los sistemas en red con muchos procesadores dis- 
tribuidos. Es facil afiadir un nuevo servidor e integrarlo con el resto del sistema o actualizar 
los servidores de forma transparente sin afectar al resto del sistema. En el Capitulo 12 se es- 
tudian con mas detalle las arquitecturas distribuidas, entre las que se encuentran las arquitec- 
turas cliente-servidor y las arquitecturas de objetos distribuidos. 

Sin embargo, puede ser necesario realizar cambios a los clientes y servidores existentes 
para obtener los mayores beneficios de la integracion de un nuevo servidor. Puede no haber 
un modelo de datos compartidos entre los servidores, y los subsistemas pueden organizar sus 
datos de formas diferentes. Esto significa que los modelos de datos especificos pueden esta- 
blecerse para cada servidor con el fin de optimizar su rendimiento. Por supuesto, si se usa una 
representacion de los datos basada en X M L , puede ser relativamente simple realizar conver- 
siones de un esquema a otro. Sin embargo, X M L es una forma ineficiente de representar los 
datos; por lo tanto, su uso puede provocar problemas de rendimiento. 



11.2.3 □ modelo de capas 

El modelo de capas de una arquitectura (algunas veces denominada modelo de maquina abs- 
tracta) organiza el sistema en capas, cada una de las cuales proporciona un conjunto de ser- 
vicios. Cada capa puede pensarse como una maquina abstracta cuyo lenguaje maquina se de- 
fine por los servicios proporcionados por la capa. Este «lenguaje» se usa para implementar el 
siguiente nivel de la maquina abstracta. Por ejemplo, una forma usual de implementar un len- 
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guaje es definirun «lenguaje maquina» ideal y compilar el lenguaje para convertirlo en codi- 
go para esta maquina. A continuacion, unpaso de traduccion adicional convierte este codigo 
de maquina abstracta en codigo de maquina real. 

Un ejemplo del modelo de capas es el modelo de referencia OS1 de protocolos de red (Zim- 
mermann, 1980), analizado en la Seccion 11.5. Otro ejemplo que ha tenido cierta influencia 
fue propuesto por Buxton {Buxton, 1980), quien sugirio un modelo de tres capas para un En- 
torno de Soporte de Programacion en Ada (APSE). La Figura 11.4 refleja la estructura de 
AP SE y muestra como integrarun sistemade gestion de configuraciones usando esta aproxi- 
macion de maquina abstracta. 

El sistema de gestion de configuraciones gestiona las versiones de los objetos y propor- 
ciona facilidades de gestion de configuraciones generales, tal y como se explica en el Capi- 
tulo 29. Para soportar estas facilidades de gestion de configuraciones, se usa un sistema de 
gestion de objetos que proporciona almacenamiento de informacion y servicios de gestion 
para los elementos de configuracion u objetos. El sistema se construye sobre un sistema de 
base de datos para proporcionar el almacenamiento basico de datos y servicios tales como ges- 
tion de transacciones, recuperacion de actualizaciones y control de acceso. La gestion de la 
base de datos usa las facilidades del sistema operativo subyacente y almacenes de ficheros en 
su implementacion. Pueden verse otros ejemplos de modelos arquitectonicos por capas en el 
Capitulo 13. 

La aproximacion por capas soporta el desarrollo incremental de sistemas. A medida que 
se desarrolla una capa, algunos de los servicios proporcionados por esa capa pueden estar 
disponibles para los usuarios. Esta arquitectura tambien soporta bien los cambios y es por- 
table. En la medida en la que su interfaz permanezca sin cambios, una capa puede reempla- 
zarse por otra capa equivalente. Ademas, cuando las interfaces de la capa cambian o se ana- 
den nuevas facilidades a una capa, solamente se ve afectada la capa adyacente. Debido a que 
los sistemas por capas localizan las dependencias de la maquina en las capas mas internas, 
es mucho mas facil proporcionar implementaciones multiplataforma de las aplicaciones de 
un sistema. Unicamente las capas mas internas dependientes de la maquina necesitan ser 
reimplementadas para tener en cuenta las facilidades de un sistema operativo o base de da- 
tos diferente. 

La desventaja de la aproximacion por capas es que la estructuracion de los sistemas pue- 
de resultar dificil. Las capas internas pueden proporcionar facilidades basicas, tales como ges- 
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tion de ficheros, que son requeridas por todos los niveles. Los servicios requeridos por un 
usuario del nivel superior pueden, por lo tanto, tenerque «atravesar» las capas adyacentes para 
tener acceso a los servicios proporcionados por los niveles inferiores. Esto trastoca el mode- 
lo, ya que implica que la capa mas externa del sistema no solamente depende de su predece- 
sora inmediata. 

El rendimiento puede tambien ser un problema debido a que algunas veces se requieren 
multiples niveles de interpretacion de comandos. Si hay muchas capas, un servicio solicitado 
desde la capa superior puede tener que ser interpretado varias veces en diferentes capas antes 
de ser procesado. Para evitar estos problemas, las aplicaciones tienen que comunicarse direc- 
tamente con las capas interiores en lugar de usar los servicios proporcionados por las capas 
adyacentes. 

113 Estilos de clescom posicion modular 

Despues de que se haya elegido la organizacion del sistema en su totalidad, es necesario de- 
cidir laaproximacion a usar para descomponer los subsistemas en modulos. No existe una dis- 
tincion rigida entre la organizacion del sistema y la descomposicion modular. Los estilos vis- 
tos en la Seccion 11.2 podrian aplicarse a este nivel. Sin embargo, los componentes de los 
modulos son normalmente mas pequenos que en los subsistemas, lo cual permite usar estilos 
alternatives de descomposicion. 

No hay una distincion clara entre subsistemas y modulos, pero resulta util pensar sobre 
ellos de la siguiente forma: 

1. Un subsistema es un sistema en si mismo, cuyo funcionamiento no depende de los 
servicios proporcionados por otros subsistemas. Los subsistemas se componen de 
modulos y tienen interfaces definidas. las cuales se usan para comunicarse con otros 
subsistemas. 

2. Un modulo es normalmente un componente de un subsistema que proporciona 
uno o mas servicios a otros modulos. A su vez este usa los servicios proporciona- 
dos por otros modulos. Esto no se suele considerar como un sistema independien- 
te. Los modulos se componen normalmente de varios componentes del sistema mas 
simples. 

Hay dos estrategias principales que se pueden usar cuando se descomponga un subsistema 
en modulos: 

1. Descomposicion orientada a objetos, en la que se descompone un sistema en un con- 
junto de objetos que se comunican. 

2. Descomposicion orientada a flujos de funciones, en la que se descompone un sistema 
en modulos funcionales que aceptan datos y los transforman en datos de salida. 

En la aproximacion orientada a objetos, los modulos son objetos con estado privado y ope- 
raciones definidas sobre ese estado. En el modelo de flujos de funciones, los modulos son 
transformaciones funcionales. En ambos casos, los modulos pueden implementarse como 
componentes secuenciales o como procesos. 

Deberia evitarse tomar decisiones prematuras acerca de la concurrencia en un sistema. La 
ventaja de evitar el diseno concurrente de un sistema es que los programas secuenciales son 
mas faciles de disenar, implementar. verificary probarque los sistemas en paralelo. Las de- 
pendencias temporales entre los procesos son dificiles de formalizar, controlary verificar. Es 
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mejordescomponer los sistemas en modulos, y entonces decidir durante ta implementacion 
si estos necesitan ejecutarse secuencialmente o en paralelo. 



11.3.1 Descomposlclon orientada a objetos 

Un modelo arquitectonico orientado a objetos estructura el sistema en un conjunto de objetos 
debilmente acoplados y con interfaces bien definidas. Los objetos realizan llamadas a los ser- 
vicios ofrecidos por otros objetos. Ya introdujimos los modelos de objetos en el Capitulo 8, 
yen el Capitulo 14 veremoscon mas detalle el diseno orientado a objetos. 

La Figura 1 1.5 es un ejemplo de un modelo arquitectonico orientado a objetos de un sis- 
tema de procesamiento de facturas. Este sistema puede emitir facturas a los clientes, recibir 
pagos, emitir recibos para estos pagos y reclamaciones para las facturas no pagadas, se utili- 
za la notacion U M L introducida en el Capitulo 8 en donde las clases de objetos tienen nom- 
bres y un conjunto de atributos asociados. Las operaciones, si las hay, se definen en la parte 
inferior del rectangulo que representa al objeto. Las flechas discontinuas indican que un ob- 
jeto usa los atributos o servicios proporcionados por otro objeto. 

Una descomposicion orientada a objetos esta relacionadacon las clases de objetos, sus atri- 
butos y sus operaciones. Cuando se implementa, los objetos se crean a partir de estas clases 
y se usan algunos modelos de control para coordinar las operaciones de los objetos. En este 
ejemplo particular, la clase Factura tiene varias operaciones asociadas que implementan la 
funcionalidad del sistema. Esta clase hace uso de otras clases que representan a los clientes, 
a los pagos y a los recibos. 

Las ventajas de la aproximacion orientada a objetos son bien conocidas. Debido a que los 
objetos estan debilmente acoplados, la implementacion de los objetos puede modificarse sin 
afectar a otros objetos. Los objetos son a menudo representaciones de entidades del mundo 
real por lo que la estructura del sistema es facilmente comprensible. Debido a que las entida- 
des del mundo real se usan en sistemas diferentes, los objetos pueden reutilizarse. Se han desa- 
rrollado lenguajes de programacion orientados a objetos que proporcionan implementaciones 
directas de componentes arquitectonicos. 

Sin embargo, la aproximacion orientada a objetos tiene desventajas. Para utilizar los ser- 
vicios, los objetos deben referenciar de forma explicita el nombre y la interfaz de otros obje- 
tos. Si se requiere un cambio de interfaz para satisfacer los cambios del sistema propuestos, 
se debe evaluar el efecto de ese cambio sobre todos los usuarios de los objetos cambiados. Si 
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bien los objetos pueden corresponderse con entidades del mundo real a pequena escala, al- 
gunas veces es dificil representar como objetos entidades mas complejas. 

11.3.2 Descomposicion orientada a flujos de funclones 

En una descomposicion orientada a flujos de funciones o modelo de flujo de datos, las trans- 
formaciones funcionales procesan sus entradas y producen salidas. Los datos fluyen de una 
funcion a otra y se transforman a medida que se mueven a traves de la secuencia de funcio- 
nes. Cadapaso de procesamiento se implementa como una transformacion. Los datos de en- 
trada fluyen a traves de estas transformaciones hasta que se convierten en datos de salida. Las 
transformaciones se pueden ejecutar secuencialmente o en paralelo. Los datos pueden ser pro- 
cesados porcada transformacion elemento a elemento o en un unico lote. 

Cuando las transformaciones se representan como procesos separados, algunas veces este 
modelo se denomina modelo de tuberia y filtro, siguiendo la terminologia usada en el siste- 
ma Unix. El sistema Unix proporciona tuberias que actuan como conductoras de datos y un 
conjunto de comandos que son las transformaciones funcionales. Los sistemas que siguen este 
modelo pueden implementarse combinando comandos Unix que usan tuberias y las facilida- 
des de control del interprete de comandos de Unix. El termino/iftrose usadebido a que una 
transformacion «filtra» los datos que puede procesar desde su flujo de datos de entrada. 

Se han usado variantes de este modelo de flujo desde que las computadoras fueron utili- 
zadas porprimera vezpara el procesamiento automatico de datos. Cuando las transformacio- 
nes son secuenciales con datos procesados por lotes, este modelo arquitectonico es un mode- 
lo secuencialpor lores. Taly como se indicaenelCapitulo 13, estaesunaarquitecturacomun 
para sistemas de procesamiento de datos tales como sistemas de facturacion. Los sistemas de 
procesamiento de datos normalmente generan muchos informes de salida que se derivan apar- 
tirde calculos simples sobre un gran numero de registros de entrada. 

Un ejemplo de este tipo de arquitectura de sistemas se muestra en la Figura 1 1.6. Una or- 
ganizacion ha emitido facturas a sus clientes. Una vez por semana, los pagos realizados se 
comparan con las facturas. Para esas facturas pagadas se emite un recibo. Para las facturas que 
no han sido pagadas dentro del plazo de pago se emite una reclamacion. 

Este es un modelo solamente de una parte del sistema de procesamiento de facturas. Se po- 
drian usar transformaciones alternativas para la emision de facturas. Note la diferencia entre 
este modelo y su equivalente orientado a objetos comentado en la seccion anterior. El mode- 
lo de objetos es mas abstracto en tanto que no incluye informacion sobre la secuencia de ope- 
raciones. 




Figura 11.6 Un modelo de flujo de funciones de un sistema de procesamiento de facturas. 
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Las ventajas de esta arquitectura son las siguientes: 

1. Permite lareutilizacion de transformaciones. 

2. Es intuitiva puesto que muchas personas piensan en su trabajo en terminos de proce- 
samiento de entradas y salidas. 

3. Generalmente se puede hacer evolucionar de forma directa el sistema anadiendo nue- 
vas transformaciones. 

4. Es sencilla de implementar ya sea como un sistema concurrente o como uno secuen- 
cial. 

El principal problema con este estilo es que tiene que haber un formato comun para trans- 
ferir los datos de forma que puedan ser reconocidos por todas las transformaciones. Cada 
transformacion debe estar acorde con las transformaciones con las que se comunica sobre 
el formato de los datos a procesar o bien se debe imponer un formato estandar para todos 
los datos comunicados. Esto ultimo es la unica aproximacion factible cuando las transfor- 
maciones son independientes y reutilizables. En Unix, el formato estandar es simplemente 
una secuencia de caracteres. Cada transformacion debe analizar su entrada y proporcionar 
la salida en el formato acordado. Esto incrementa la sobrecarga del sistema y puede signi- 
ficar que sea imposible integrar transformaciones que utilicen formatos incompatibles de 
datos. 

Los sistemas interactivos son dificiles de describirusando el modelo de flujo de funciones 
debido a la necesidad de un flujo de datos a procesar. Mientras que un modelo textual senci- 
llo de entradas y salidas puede modelarse de esta forma, las interfaces graficas de usuario tie- 
nen formalos de entrada/salida mas complejos y controles, los cuales se basan en eventos ta- 
les como pulsaciones del raton o selecciones de menus. Es dificil traducir esto a una forma 
compatible con el modelo de flujo de funciones. 

11.4 Estilos de control 

Los modelos para estructurar un sistema estan relacionados con la forma en que un sistema 
se descompone en subsistemas. Para trabajarcomo un sistema, los subsistemas deben sercon- 
trolados para que sus servicios se entreguen en el lugar correcto en el momenta preciso. Los 
modelos estructurales no incluyen (y no deberian hacerlo) informacion de control. En su lu- 
gar, el arquitecto deberia organizar los subsistemas de acuerdo con algun modelo de control 
que complemente el modelo de estructura usado. Los modelos de control a nivel arquitecto- 
nico estan relacionados con el flujo de control entre subsistemas. 

Hay dos estilos de control genericos que se usan en sistemas software: 

1. Control centralizado. Un subsistema tiene toda la responsabilidad para controlar e ini- 
ciar y detener a otros subsistemas. Tambien puede devolver el control a otro subsiste- 
ma, pero esperara que le sea devuelta la responsabilidad del control. 

2. Control basado en eventos. En lugar de que la informacion de control este embebida 
en un subsistema, cada subsistema puede responder a eventos generados externamen- 
te. Estos eventos podrian provenir de otros subsistemas o del entorno del sistema. 

Los estilos de control se usan conjuntamente con estilos estructurales. Todos los estilos es- 
tructurales analizados se pueden llevar a cabo utilizando control centralizado o control basa- 
do en eventos. 
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11.4.1 Control centrallzado 



En un modelo de control centralizado, un subsistema se disefia como el controladordel siste- 
ma y tiene la responsabilidad de gestionar la ejecucion de otros subsistemas. Los modelos de 
control centralizado se dividen en dos clases, segun que los subsistemas controlados se eje- 
cuten secuencialmente o en paralelo. 

1 . El modelo de llamada-retorno. Es el modelo usual de subrutina descendente en don- 
de el control comienza al inicio de unajerarquia de subrutinas y, a traves de las 11a- 
madas a subrutinas. el control pasa a niveles inferiores en el arbol de lajerarquia. El 
modelo de subrutinas solamente es aplicable a sistemas secuenciales. 

2. El modelo del gestor. Este es aplicable a sistemas concurrentes. Un componente del 
sistema se disena como un gestor del sistema y controla el inicio, parada y coordina- 
cion del resto de los procesos del sistema. Un proceso es un subsistema o modulo que 
puede ejecutarse en paralelo con otros procesos. Una variante de este modelo tambien 
puede aplicarse a sistemas secuenciales en los que la rutina de gestion llama a subsis- 
temas particulares dependiendo de los valores de algunas variables de estado. Esto nor- 
malmente se implementa como una sentencia case. 

El modelo de llamada-retomo se ilustraen laFigura 1 1.7. El programaprincipal puede 11a- 
mar a las Rutinas 1, 2 y 3; la Rutina I puede llamar a las Rutinas 1.1 o 1.2; la Rutina 3 pue- 
de llamar a las rutinas 3.1 o 3.2; y asi sucesivamente. Este es un modelo que muestra la dina- 
mica del programa. No es un modelo estructural; no es necesario que la Rutina 1.1, por 
ejemplo, sea parte de la Rutina 1. 

Este modelo familiar esta embebido en lenguajes de programacion tales como C, Ada y 
Pascal. Las subrutinas en un lenguaje de programacion que son llamadas por otras subrutinas 
son naturalmente funcionales. Sin embargo, en muchos sistemas orientados aobjetos, las ope- 
raciones sobre los objetos (metodos) se implementan como procedimientos o funciones. Por 
ejemplo, cuando un objeto Java solicita un servicio de otro objeto, lo hace llamando a un me- 
todo asociado a dicho objeto. 

La naturaleza rigida y restrictiva de este modelo es tanto una ventaja como un inconve- 
niente. Es una ventaja debido a que es relativamente simple analizar flujos de control y co- 
nocer como respondera el sistema a cierto tipo de entradas. Es un inconveniente debido a que 
las excepciones a las operaciones normales son tediosas de manejar. 

La Figura 1 1.8 ilustra un modelo de gestion de control centralizado para un sistema con- 
currente. Este modelo se usa a menudo en sistemas de tiempo real «blandos», los cuales no 
tienen restricciones de tiempo muy estrictas. El controlador central gestiona la ejecucion de 
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Flgura 11.8 
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un conjunto de procesos asociados con sensores y actuadores. La construccion del sistema de 
monitorizacionexplicadaenel Capitulo 15 usa este modelo de control. 

El proceso controlador del sistema decide cuando deberian comenzar o terminar los pro- 
cesos dependiendo de las variables de estado del sistema. El sistema comprueba si otros pro- 
cesos han producido informacion para ser procesada o para enviarles informacion para su pro- 
cesamiento. El controlador por lo general realiza ciclos continuamente, consultando los 
sensores y otros procesos para detectar eventos o cambios de estado. Por esta razon, este mo- 
delo se llama algunas veces modelo de ciclo de eventos. 

11.4.2 Slstemas dlrlgldos por eventos 

En los modelos de control centralizados, las decisiones de control se determinan normalmente 
por los valores de algunas variables de estado del sistema. Por el contrario, los modelos de 
control dirigidos por eventos se rigen por eventos generados externamente. E 1 termino even- 
to en este contexto no solo significa una seflal binaria. Puede ser una senal dentro de un ran- 
go de valores o una entrada de un comando desde un menu. La diferencia entre un evento y 
una entrada simple es que la aparicion del evento esta fuera del control del proceso que ma- 
neja ese evento. 

Hay muchos tipos de sistemas dirigidos por eventos. Estos incluyen editores, en donde los 
eventos de la interfaz de usuario provocan la ej ecucion de comandos; sistemas de produccion 
basados en reglas, como los usados en AI, en donde una condicion que se convierte en ver- 
dadera provoca que se dispare una accion, y los objetos activos, en los que cambiar un valor 
de un atributo del objeto dispara algunas acciones. Garlan y otros (Garlan et ai, 1992) estu- 
dian estos diferentes tipos de sistemas. 

En esta seccion, se analizan dos modelos de control dirigidos por eventos: 

1 . Modelos de transmision (broadcast). En estos modelos, un evento se transmite a to- 
dos los subsistemas. Cualquier subsistema que haya sido programado para manejar ese 
evento puede responder a el. 

2. Modelos dirigidos por interrupciones. Estos se usan exclusivamente en sistemas de 
tiempo real, en donde las interrupciones externas son detectadas por un manejador de 
interrupciones. A continuacion, estas se envian a algun otro componente para su pro- 
cesamiento. 
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Los modelos de transmision son efectivos para integrar subsistemas distribuidos en dife- 
rentes computadoras de una red. Los modelos dirigidos por interrupciones se usan en siste- 
mas de tiempo real con requerimientos temporales rigidos. 

En un modelo de transmision (Figura 1 1.9), los subsistemas registran un interes en even- 
tos especificos. Cuando estos eventos ocurren, el control se transfiere al subsistema que pue- 
de manejar el evento. La diferencia entre este modelo y el modelo centralizado mostrado en 
la Figura 11.8 es que la politica de control no esta embebida en el manejador de eventos y 
mensajes. Los subsistemas deciden que eventos requieren y el manejador de eventos y men- 
sajes asegura que estos eventos sean enviados a dichos subsistemas. 

Todos los eventos podrian enviarse a todos los subsistemas, pero esto supondria una gran 
sobrecarga de procesamiento. A menudo, el manejador de eventos y de mensajes mantiene un 
registro de los subsistemas y de los eventos que a estos les interesan. Los subsistemas gene- 
ran eventos que indican, quizas, que algun dato esta disponible para su procesamiento. El ma- 
nejador de eventos detecta los eventos, consulta el registro de eventos y envia el evento a aque- 
llos subsistemas que han declarado un interes por el. 

En sistemas mas simples, tales como sistemas basados en PCs dirigidos por eventos de in- 
terfaz de usuario, hay subsistemas explicitos que actuan como oyentes de eventos que estan 
a la espera de eventos provenientes del raton, el teclado, y otros, y los traducen en comandos 
mas especificos. 

El manejador de eventos tambien soporta normalmente comunicaciones punto a punto. Un 
subsistema puede enviar un mensaje de forma explicita a otro subsistema. Hay diversas va- 
riantes de este modelo, tales como el entornode Field (Reiss, 1990)y el Softbenchde Hewlett- 
Packard (Fromme y Walker, 1993). Ambos se han utilizado para controlar las interacciones 
de las herramientas en entornos de ingenieria del software. Los intermediarios de peticiones 
de objetos (ORBs), estudiados en el Capitulo 12, tambien soportan este modelo de control 
para comunicaciones de objetos distribuidos. 

La ventaja de esta aproximacion de transmision (broadcast) es que la evolucion es relati- 
vamente simple. Un nuevo subsistema puede integrarse para manejar clases particulares de 
eventos registrando sus eventos con el manejador de eventos. Cualquier subsistema puede ac- 
tivar otros subsistemas sin conocer su nombre o localizacion. Los subsistemas pueden im- 
plementarse sobre maquinas distribuidas. Esta distribucion es transparente para el resto de los 
subsistemas. 

La desventaja de este modelo es que los subsistemas no conocen si los eventos se maneja- 
ran ni cuando seran manejados. Cuando un subsistema genera un evento no conoce que sub- 
sistemas han registrado un interes en dicho evento. Es bastante probable que subsistemas di- 
ferentes se registren para los mismos eventos. Esto puede ocasionar conflictos cuando estan 
disponibles los resultados del manejo del evento. 

Los sistemas de tiempo real que requieren que los eventos generados externamente sean 
manejados muy rapidamente, deben ser conducidos por eventos. Por ejemplo, si un sistema 



(Subsistema^ f Subsistema^ f Subsistema^ f Subsistema^ 
7 J \ 2 J \ 3 J v 4 J 



Figura 11.9 

Un modelo de 
control basado en 
transmision 
selectiva. 



1 


5 








Manejador de eventos y mensajes | 



236 CAPITULO 11 • Dlseno arqultectonlco 

de tiempo real se usa para controlar la seguridad del sistema en un vehiculo, debe detectar un 
posible choque y, quizas, inflar el airbag antes de que la cabeza del conductor impacte sobre 
el volante. Para proporcionar esta respuesta rapida a los eventos, se debe usar un control di- 
rigido por interrupciones. 

Un modelo de control dirigido por interrupciones se ilustra en la Figura 11.10. Hay varios 
tipos de interrupciones conocidos con un manejador definido para cada uno de ellos. Cada tipo 
de interrupcion se asociaconuna localizacion de memoria endonde se almacena ladireccion 
del manejador. Cuando se recibe una interrupcion de un tipo particular, un conmutador hard- 
ware hace que el control se transfiera inmediatamente a este manejador. Este manejador de 
interrupciones puede entonces iniciar o detener a otros procesos en respuesta al evento sena- 
lizado por la interrupcion. 

Este modelo se usa principalmente en sistemas de tiempo real en los que es necesaria una 
respuesta inmediata a algun evento. Puede ser combinada con el modelo de gestion centrali- 
zado. El gestor central maneja la ejecucion normal del sistema con un control para emergen- 
cias basado en interrupciones. 

La ventaja de esta aproximacion es que permite implementar respuestas muy rapidas a los 
eventos. Sus desventajas son que es complejo de programar y dificil de validar. Puede ser im- 
posible replicar patrones de ocurrencias de las interrupciones durante la prueba del sistema. 
Puede ser dificil cambiar los sistemas desarrollados usando este modelo si el numero de in- 
terrupciones esta limitado por el hardware. Una vez que se alcanza este limite, no puede ma- 
nejarse ningun otro tipo de eventos. Se puede algunas veces obviar esta limitacion haciendo 
corresponder varios tipos de eventos con una unica interrupcion. El manejador entonces co- 
noce que evento ha tenido lugar. Sin embargo, la correspondencia de interrupciones puede no 
ser practica si se requiere una respuesta muy rapida a interrupciones individuates. 

11.5 Arquitecturas de referenda 

Los modelos arquitectonicos citados anteriormente son modelos generales: pueden aplicarse 
a muchas clases de aplicaciones. Al igual que los modelos generales, tambien pueden usarse 
los modelos arquitectonicos que son especificos para un dominio particular de aplicacion. Si 
bien las instancias de estos sistemas difieren en los detalles, la estructura arquitectonica co- 
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mun puede reutilizarse cuando se desarrollan nuevos sistemas. Estos modelos arquitectoni- 
cos se denominan arquitecturas de dominio espectfico. 

Haydos tiposde modelos arquitectonicos de dominio especifico: 

1 . Modelos genericos. Son abstracciones obtenidas a partir de varios sistemas reales. En- 
capsulan las caracteristicas principales de estos sistemas. Por ejemplo, en sistemas de 
tiempo real, podriahaber modelos arquitectonicos genericos de diferentes tipos de sis- 
temas tales como sistemas de recoleccion de datos o sistemas de monitorizacion. Se 
estudian varios modelos genericos en el Capitulo 13, que incluye las arquitecturas de 
aplicaciones. Esta seccion se centra en los modelos de referencia arquitectonicos. 

2. Modelos de referencia. Son mas abstractos y describen una clase mas amplia de sis- 
temas. Constituyen un modo de informar a los disefiadores sobre la estructura general 
de esta clase de sistemas. Los modelos de referencia normalmente se obtienen a par- 
tir de un estudio del dominio de la aplicacion. Representan una arquitectura ideal que 
incluye todas las caracteristicas que los sistemas podrian incorporar. 

No hay, desde luego, una distincion rigida entre estos tipos de modelos. Los modelos ge- 
nericos tambien pueden servircomo modelos de referencia. Hacemos aqui la distincion entre 
ellos debido a que los modelos genericos pueden reutilizarse directamente en un diseflo. Los 
modelos de referencia se usan normalmente para comunicar conceptos del dominio y com- 
parar o evaluar posibles arquitecturas. 

Las arquitecturas de referencia normalmente no se consideran como un camino para la im- 
plementacion. En su lugar, su principal funcion es una forma de tratar arquitecturas especifi- 
cas del dominio y de comparar sistemas diferentes en un dominio. Un modelo de referencia 
proporciona un vocabulario para realizar comparaciones. Dicho modelo actua como una base, 
frente a la cual los sistemas pueden ser evaluados. 

El modelo OSI es un modelo de siete capas para la interconexion de sistemas abiertos. 
El modelo se ilustra en la Figura 11.11. Las funciones exactas de las capas no son impor- 
tantes aqui. En esencia, las capas inferiores estan relacionadas con la interconexion fisica, 
las capas intermedias con la transferencia de los datos y las capas superiores con la trans- 
ferencia de informacion de la aplicacion semanticamente significativa como documentos es- 
tandarizados. 

Los disefiadores del modelo OSI tuvieronel objetivopractico de definiruna implementa- 
cion estandar para que los sistemas acordes con ella pudiesen comunicarse unos con otros. 
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Cada capa solamente deberia depender de la capa inmediatamente inferior. A medida que se 
desarrollan nuevas tecnologias, una capa podria ser reimplementada de forma transparente sin 
afectar a los sistemas que usan el resto de las capas. 

En lapractica, sin embargo, los problemas de rendimiento de la aproximacion por capas 
para el modelado arquitectonico han comprometido este objetivo. Debido a las grandes dife- 
rencias entre las redes, una simple interconexion puede ser imposible. Si bien las caracteris- 
ticas funcionales de cada capa estan bien definidas, las caracteristicas no funcionales no es- 
tan definidas. Los desarroliadores del sistema tienen que implementar sus propias facilidades 
de mas alto nivel y omitir algunas capas del modelo. De forma alternativa, tienen que disenar 
caracteristicas no estandares para mejorar el rendimiento del sistema. 

Como consecuencia, el reemplazo de una capa en el modelo de forma transparente es real- 
mente muy dificil. Sin embargo, esto no niega la utilidad del modelo ya que proporciona una 
base para laestructuracion abstractay la implementacion sistematica de comunicaciones en- 
tre los sistemas. 

Otro modelo de referencia propuesto es un modelo de referencia para entornos CASE 
(ECMA, 1991; Brown et ah, 1992) que identifica cinco conjuntos de servicios queunentor- 
no CASE deberia proporcionar. Tambien deberia proporcionar facilidades «plug-in» para he- 
rramientas CASE individuals que utilizan estos servicios. El modelo de referencia CASE se 
ilustra en la Figura 1 1 . 12. Los cinco niveles de servicio en el modelo de referencia CASE son: 

1. Servicios de repositorio de datos. Proporcionan facilidades para el almacenamiento y 
gestion de los elementos de datos y sus relaciones. 

2. Servicios de integration de datos. Proporcionan facilidades para gestionar grupos o el 
establecimiento de relaciones entre ellos. Estos servicios y los servicios de reposito- 
rio de datos son las bases de la integracion de datos en el entorno. 

3 . Servicios de gestion de tareas. Proporcionan facilidades para la definicion y estableci- 
miento de normas de los modelos de proceso. Soportan integracion de procesos. 

4. Servicios de mensajes. Estos proporcionan facilidades para comunicaciones herra- 
mienta-herramienta, entorno-herramienta y entorno-entorno. Soportan la integracion 
del control. 

5 . Servicios de interfaz de usuario. Proporcionan facilidades para el desarrollo de inter- 
faces de usuario. Soportan la integracion de lapresentacion. 

Este modelo de referencia nos dice lo que deberia incluirse en cualquier entorno CASE par- 
ticular, si bien es importante destacar que no se incluira en los diseflos arquitectonicos reales 
cada caracteristica de una arquitectura de referencia. Esto significa que nosotros podemos 
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plantear cuestiones sobre el diseno de un sistema del tipo «^como se proporcionan los servi- 
cios del repositorio de datos?» y «^el sistema proporciona gestion de tareas?». 

Una vez mas, el principal valor de estas arquitecturas de referencia es que sirven como una 
forma de clasificar y comparar entornos y herramientas CASE integradas. Ademas, tambien 
pueden usarse en entornos educativos para resaltar las caracteristicas clave de estos entornos 
y considerarlos de una forma generica. 



PUNTOS CLAVE 

• La arquitectura det software es el marco fundamental para estructurar el sistema. Las propiedades de un sis- 
tema tales como rendimiento, seguridad y disponibilidad est an influenciadas por la arquitectura utilizada. 

• Las decisiones dedisenoarquitectdnico incluyen decisiones sobre el tipo deaplicacidn, la distribution del sis- 
tema, los estilos arquitectdnicosa utilizary lasformas en las que la arquitectura deberia documentarseyeva- 
luarse. 

• Diferentes modelos arquitectdnicos tales como un modelo estructural, un modelo de control y un modelo de 
descomposicidnpuedenserdesarrolladosduranteelprocesodedisenoarquitectdnico. 

• Los modelos organizacionales de un sistema comprenden los modelos de repositorio, los modelos cliente-ser- 
vidory los modelos de maquina abstracta. Los modelos de repositorio comparten datos a traves de un alma- 
cen comun. Los modelos cliente-servidornormalmentedistribuyen los datos. Los modelos de maquina abs- 
tracta se organizan en capas, implementando cada capa utilizando las facilidades proporcionadas por la capa 
adyacente. 

• Losestilosdedescomposicidncomprenden la descom posicidn orientada a funcionesy la orientadaa objetos. 
Los modelos orientados a flujo son funcionales y los modelos de objetos se basan en entidades pobremente 
acopladas que mantienen su propio estado y operaciones. 

• Los estilos de control incluyen control centralizado ycontrol basado en eventos. En los modelos centralizados 
de control, las decisiones de control se toman dependiendo del estado del sistema; en los modelos de even- 
tos, tos eventos externos controlan el sistema. 

• Las arquitecturas de referencia pueden usarse como una forma de estudiar arquitecturas especif icas det do- 
minio yevaluary comparar di sen os arquitectdnicos. 



LECTURAS ADICIONALES MBHHHHHflili 

Software Architecture in Practice, 2nd ed. Es un estudio practico de arquitecturas software sin exagerar en su pre- 
sentacion y que proporciona una clara exposicion razonada para las empresas de por que las arquitecturas son im- 
portantes. (L. Basseia/., 2003, Addison-Wesley.) 

Design and Use of Software Architectures. Si bien este libro se centra en arquitecturas de lineas de productos, los 
primeros capitulos son una introduccion excelente a las cuestiones generales en el diseno de la arquitectura del soft- 
ware. 0- Bosch, 2000, Addison-Wesley.) 



240 CAPITU L0 11 • Diseno arqultectonico 



Software Architecture: Perspectives on an Emerging Discipline. Este fue el primer libro sobre arquitecturas softwa- 
re y tieneunbuen estudio sobre diferentes estilosarquitectonicos. (M. Shawy D. Garlan, 1996, Prentice-Hall.) 



EJERCICIOS 

111 Explique por que puede ser necesario disenar la arquitectura del sistema antes de redactar las especifica- 
ciones. 

112 Explique por que podrian tener lugar connictos de diseno al disefiaruna arquitectura en la que los reque- 
rimientos de disponibilidad y seguridad son tos requerimientos no funcionales mas importantes. 

1L3 Construya una tabla que muestre las ventajas e inconvenientes de los modelos estructurales analizados 
en estecapitulo. 

114 Sugiera, justificando sus respuesta, un modelo estructural adecuado para los siguientes sistemas: 

• Un sistema de venta automatica de billetes usados por los pasajeros en una estacion de trenes. 

• Un sistema de videoconferencia controlada por computadora que permita que el video, audio y datos 
de (a computadora esten disponibles para varios participantes al mismo tiempo. 

• Un robot limpiador de suelos que tenga como objetivo limpiar espacios relativamente vacios tales como 
pasillos. El limpiador debe sercapaz de detectar paredesy otros obstaculos. 

1L5 Disene una arquitectura para los sistemas anteriores basada en el modelo que usted ha elegido. Haga su- 
posiciones razonables sobre los requerimientos del sistema. 

1L6 Los sistemas de tiempo real normalmente utilizan modelos de control dirigidos por eventos. ^En que cir- 
cunstancias podria recomendar el uso de un modelo de control de llamada-retorno para un sistema de 
tiempo real? 

1L7 Sugiera, justificando su respuesta, un modelo de control adecuado para los siguientes sistemas: 

• Un sistema de procesamiento por lotes que tenga como entrada la informacion sobre las horas traba- 
jadas y tarifas de pago e imprima informacion sobre hojas de salarios y la informacion bancaria de la 
transferencia de estos. 

• Un conjunto de herramientas software que son producidas por diferentes vendedores, pero que tienen 
que trabajar conjuntamente. 

• Un controlador de television que responde a las senales de una unidad de control remoto. 

1L8 Comente las ventajas e inconvenientes relacionados con la capacidad de distribucion del modelo de flujo 
de datos y el modelo de objetos. Suponga que se requieren tanto versiones distribuidas como versiones 
con una unica maquina. 

11.9 Se le han proporcionado dos conjuntos de herramientas CASE integradas y se le ha solicitado que las com- 
pare. Explique como podria usar un modelo de referencia para herramientas CASE (Brown et m, 1992) para 
hacerestacomparacion. 

1L10 ^Deberia existir una profesion de «arquitecto software)) cuyo cometido fuese trabajar de forma indepen- 
diente con un cliente para disenar una arquitectura de un sistema software? El sistema entonces deberia 
ser implementado por alguna compania de software. ^Cuales podrian ser las dificultades del estableci- 
miento de una profesion como esta? 
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de sistemas distribuidos 



Objetivos 

El objetivo de este capitulo es estudiar modelos de arquitectura 
del software para sistemas distribuidos. Cuando haya leido este 
capitulo: 

• conocera las ventajas y desventajas de las arquitecturas de 
sistemas distribuidos; 

• comprendera los dos modelos principales de arquitecturas de 
sistemas distribuidos, denominados sistemas cliente-servidor 
y sistemas de objetos distribuidos; 

• comprendera el concepto de un objeto intermediario de 
peticiones y los principios que subyacen a tos estandares 
CORBA; 

• se habra introducido en las arquitecturas de igual a igual 
(peer-to-peer) y arquitecturas orientadas a servicios. 



Contenidos 

12.1 Arquitecturas multiprocesador 

12.2 Arquitecturas cliente-servidor 

12.3 Arquitecturas de objetos distribuidos 

12.4 Computacion distribuida interorganizacional 
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Practicamente todos los grandes sistemas informaticos son en la actualidad sistemas distri- 
buidos. Un sistemadistribuido esun sistema en el que el procesamiento de informacion se dis- 
tribuye sobre varias computadoras en vez de estar confinado en una unica maquina. Obvia- 
mente, la ingenieria de sistemas distribuidos tiene mucho en comun con la ingenieria de 
cualquier otro software, pero existen cuestiones especificas que deben tenerse en cuenta cuan- 
do se disena este tipo de sistemas. Ya se han presentado algunas de estas cuestiones en la in- 
troduccion a las arquitecturas el i ente-servidor en el Capitulo 1 1 y se explican aqui con mayor 
detalle. 

Coulourisy otros (Coulouris etal., 2001) estudian lascaracteristicas importantes de los sis- 
temas distribuidos. Identifican las siguientes ventajas del uso de una aproximacion distribui- 
da para el desarrollo de sistemas: 

1. Comparticion de recursos. Un sistema distribuido permite compartir recursos hard- 
ware y software — como discos, impresoras, ficheros y compiladores — que se asocian 
con computadoras de una red. 

2. Apertura. Los sistemas distribuidos son normalmente sistemas abiertos, lo que signi- 
fica que se disenan sobre protocolos estandarquepermitencombinarequipamientoy 
software de diferentes vendedores. 

3. Concurrencia. En un sistema distribuido, varios procesos pueden operar al mismo 
tiempo sobre diferentes computadoras de la red. Estos procesos pueden (aunque no ne- 
cesariamente) comunicarse con otros durante su funcionamiento normal. 

4. Escalabilidad. Al menos en principio, los sistemas distribuidos son escalables en tanto 
que la capacidad del sistema puede incrementarse anadiendo nuevos recursos para cu- 
brir nuevas demandas sobre el sistema. En la practica, la red que une las computadoras 
individuales del sistema puede limitar la escalabilidad del sistema. Si se afiaden muchas 
computadoras nuevas, entonces la capacidad de la red puede resultar inadecuada. 

5. Tolerancia a defectos. La disponibilidad de varias computadoras y el potencial para 
reproducir informacion significa que los sistemas distribuidos pueden ser tolerantes a 
algunos fallos de funcionamiento del hardware y del software (vease el Capitulo 20). 
En la mayoria de los sistemas distribuidos, se puede proporcionar un servicio degra- 
dado cuando ocurren fallos de funcionamiento; una completaperdidade servicio solo 
ocurre cuando existe un fallo de funcionamiento en la red. 

Para sistemas organizacionales a gran escala, estas ventajas significan que los sistemas dis- 
tribuidos han reemplazado ampliamente a los sistemas heredados centralizados que fueron 
desarrollados en los anos 80 y 90. Sin embargo, comparados con sistemas que se ejecutan so- 
bre un unico procesador o un cluster de procesadores, los sistemas distribuidos tienen varias 
desventajas: 

1. Complejidad. Los sistemas distribuidos son mas complejos que los sistemas centrali- 
zados. Esto hace mas dificil comprender sus propiedades emergentes y probar estos 
sistemas. Por ejemplo, en vez de que el rendimiento del sistema dependa de la veloci- 
dad de ejecucion de un procesador, depende del ancho de banda y de la velocidad de 
los procesadores de la red. Mover los recursos de una parte del sistema a otra puede 
afectar de forma radical al rendimiento del sistema. 

2. Seguridad. Puede accederse al sistema desde varias computadoraes diferentes, y el tra- 
fico en la red puede estar sujeto a escuchas indeseadas. Esto hace mas dificil el ase- 
gurar que la integridad de los datos en el sistema se mantenga y que los servicios del 
sistema no se degraden por ataques de denegacion de servicio. 
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3. Manejabilidad. Las computadoras en un sistema pueden ser de diferentes tipos y pue- 
den ejecutar versiones diferentes de sistemas operativos. Los defectos en una maqui- 
na pueden propagarse a otras maquinas con consecuencias inesperadas. Esto signifi- 
ca que se requiere mas esfuerzo para gestionar y mantener el funcionamiento del 
sistema. 

4. Impredecibilidad. Como todos los usuarios de la W W W saben, los sistemas distribui- 
dos tienen una respuesta impredecible. La respuesta depende de la carga total en el sis- 
tema, de suorganizaciony de la carga de la red. Como todos ellos pueden cambiarcon 
mucha rapidez, el tiempo requerido para responder a una peticion de usuario puede va- 
riar drasticamente de una peticion a otra. 

El reto para el diseno es disefiar el software y hardware para proporcionar caracteristicas 
deseables a los sistemas distribuidos y. al mismo tiempo, minimizar los problemas inherentes 
a estos sistemas. Para hacer eso. se necesita comprender las ventajas y desventajas de las di- 
ferentes arquitecturas de sistemas distribuidos. Aqui se tratan dos tipos genericos de arqui- 
tecturas de sistemas distribuidos: 

1. Arquitecturas cliente-servidor. En esta aproximacion, el sistema puede ser visto como 
un conjunto de servicios que se proporcionan a los clientes que hacen uso de dichos 
servicios. Los servidores y los clientes se tratan de forma diferente en estos sistemas. 

2. Arquitecturas de objetos distribuidos. En este caso, no hay distincion entre servidores 
y clientes, y el sistema puede ser visto como un conjunto de objetos que interaccionan 
cuya localizacion es irrelevante. No hay distincion entre un proveedorde servicios y 
el usuario de estos servicios. 

Ambas arquitecturas se usan ampliamente en la industria, pero la distribucion de las apli- 
caciones generalmente tiene lugar dentro de unaunicaorganizacion. La distribucion soporta- 
da es, por lo tanto, intraorganizacional. Aqui tambien planteamos dos tipos mas de arquitec- 
turas distribuidas que son mas adecuadas para la distribucion interorganizacional: arquitectura 
de sistemas peer-to-peer (p2p) y arquitecturas orientadas a servicios. Los sistemas peer-to-peer 
han sido usados principalmente para sistemas personales, pero estan comenzando a usarse para 
aplicaciones de empresa. En el momenta de escribir este libro, se estaban introduciendo los 
sistemas orientados a servicios, pero la aproximacion orientada a servicios probablemente se 
convertira en un modelo de distribucion significativo en 2005. 

Los componentes en un sistema distribuido pueden implementarse en diferentes lenguajes 
de programacion y pueden ejecutarse en tipos de procesadores completamente diferentes. Los 
modelos de datos, la representacion de la informacion y los protocolos de comunicacion pue- 
den ser todos diferentes. Un sistema distribuido, por lo tanto, requiere software que pueda ges- 
tionar estas partes distintas, y asegurar que dichas partes se puedan comunicar e intercambiar 
datos. El termino middleware se usa para hacer referencia a ese software; se situa en medio 
de los diferentes componentes distribuidos del sistema. 

Bernstein {Bernstein, 1996) resume los tipos de middleware disponibles para soportar 
computacion distribuida. El middleware es un software de proposito general que normalmente 
se compra como un componente comercial mas que escribirse especialmente por los des- 
arrolladores de la aplicacion. Ejemplos de middleware son software para gestionar comuni- 
caciones con bases de datos, administradores de transacciones, convertidores de datos y con- 
troladores de comunicacion. Mas adelante en este capitulo se describen los denominados 
intermediaries de peticiones de objetos (object request broker), que constituyen una clase im- 
portante de middleware para sistemas distribuidos. 
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Los sistemas distribuidos se desarrollan nonnalmente utilizando una aproximacion orien- 
tada a objetos. Estos sistemas estan formados por partes independientes pobremente integra- 
das, cada una de las cuales puede interaccionar directamente con los usuarios o con otras par- 
tes del sistema. Algunas partes del sistema pueden tener que responder a eventos 
independientes. Los objetos software reflejan estas caracteristicas; por lo tanto, son abstrac- 
ciones naturales para los componentes de sistemas distribuidos. 



12.1 Arquitecturas multiprocesador 

El modelo mas simple de un sistema distribuido es un sistema multiprocesador en el que el 
sistema software esta formado por varios procesos que pueden (aunque no necesariamente) 
ejecutarse sobre procesadores diferentes. Este modelo es comun en sistemas grandes de tiem- 
po real. Tal y como se expone en el Capitulo 15, estos sistemas recogen informacion, toman 
decisiones usando esta informacion y envian senales a los actuadores que modifican el entor- 
no del sistema. 

Logicamente, los procesos relacionados con la recopilacion de informacion, toma de de- 
cisiones y control de actuadores podrian ejecutarse todos ellos sobre un unico procesador 
bajo el control de un planificador (scheduler). El uso de multiples procesadores mejora el 
rendimiento y adaptabilidad del sistema. La distribucion de procesos entre los procesado- 
res puede ser predeterminada (esto es comun en sistemas criticos) o puede estar bajo el 
control de un despachador (dispatcher) que decide que procesos se asignan a cada proce- 
sador. 

Un ejemplo de este tipo de sistemas se muestra en la Figura 12.1. Este es un modelo sim- 
plificado de sistema de control de trafico. Un conjunto de sensores distribuidos recogen in- 
formacion sobre el flujo de trafico y la procesan localmente antes de enviarla a una sala de 
control. Los operadores toman decisiones usando esta informacion y dan instrucciones a un 
proceso de control de diversas luces de trafico. En este ejemplo, hay varios procesos logicos 
para gestionar los sensores, la salade control y los semaforos. Estos procesos logicos pueden 
ser procesos individuales o un grupo de procesos. En este ejemplo, se ejecutan sobre proce- 
sadores diferentes. 
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Figura 12.1 Un sistema multiprocesador de control de trafico 
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Los sistemas software compuestos de multiples procesos no son necesariamente sistemas 
distribuidos. Si se dispone de mas de un procesador, entonces se puede implementar la dis- 
tribucion, pero los disenadores del sistema no siempre consideran forzosamente cuestiones de 
distribucion durante elproceso de diseno. La aproximacionde diseno para estetipo de siste- 
mas es esencialmente la misma que para sistemas de tiempo real, tal y como se explica en el 
Capitulo 15. 

12.2 Arquitecturas cliente-servidor 

Ya hemos introducido el concepto de arquitecturas cliente-servidor en el Capitulo 1 1 . En una 
arquitectura cliente-servidor, una aplicacion se modela como un conjunto de servicios pro- 
porcionados por los servidores y un conjunto de clientes que usan estos servicios (Orfali y 
Harkey, 1998). Los clientes necesitan conocer que servidores estan disponibles, pero nor- 
malmente no conocen la existencia de otros clientes. Clientes y servidores son procesos dife- 
rentes, como se muestra en la Figura 12.2, que representa un modelo logico de una arquitec- 
tura distribuida cliente-servidor. 

Varios procesos servidores pueden ejecutarse sobre un unico procesador servidor; por lo 
tanto, no hay necesariamente una correspondencia 1:1 entre procesos y procesadores en el sis- 
tema. La Figura 12.3 muestra la arquitectura fisica de un sistema con seis computadoras 
cliente y dos computadoras servidor. Estos pueden ejecutar los procesos cliente y servidor 
mostrados en la Figura 12.2. Cuando hacemos referencia a clientes y servidores, nos referi- 
mos a los procesos logicos en vez de a las computadoras fisicas sobre las que se ejecutan. 

El diseno de sistemas cliente-servidor deberia reflejar la estructura logica de la aplica- 
cion que se esta desarrollando. Una forma de ver una aplicacion se ilustra en la Figura 12.4, 
que muestra una aplicacion estructurada en tres capas. La capa de presentacion esta rela- 
cionada con la presentacion de la informacion al usuario y con toda la interaccion con el. 
La capa de procesamiento de la aplicacion esta relacionada con la implementacion de la lo- 
gica de la aplicacion, y la capa de gestion de datos esta relacionada con todas las operacio- 
nes sobre la base de datos. En los sistemas centralizados, estas capas no es necesario que 
esten claramente separadas. Sin embargo, cuando se esta diseflando un sistema distribuido, 




R^ra 12.2 Un sistema cliente-servidor. 
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Figura 12.3 
Computadoras en 
una red cliente- 
servidor. 




Figura 12.4 Capas 
de las aplicaciones. 
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deberia hacerse una clara distincion entre ellas, de forma que sea posible distribuir cada 
capa sobre una computadora diferente. 

La arquitectura cliente-servidor mas simple se denomina arquitectura cliente-servidor de 
dos capas, en laqueunaaplicacion seorganiza comoun servidor (o multiples servidores iden- 
ticos) y un conjunto de clientes. Como se ilustra en la Figura 12.5. las arquitecturas cliente- 
servidor de dos capas pueden ser de dos tipos: 

1. Modelo de cliente ligero (thin-client). En un modelo de cliente ligero, todo el proce- 
samiento de las aplicaciones y la gestion de los datos se lleva a cabo en el servidor. El 
cliente simplemente es responsable de la capa de presentacion del software. 
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2. Modelo de cliente rico (fat-client). En este modelo, el servidor solamente es respon- 
sablede la gestion de losdatos. El software del cliente implementa la logicade la apli- 
cacion y las interacciones con el usuario del sistema. 

Una arquitectura de dos capas con clientes ligeros es la aproximacion mas simple que se 
utiliza cuando los sistemas heredados centralizados, como se indica en el Capitulo 2, evolu- 
cionan a una arquitectura cliente-servidor. La interfaz de usuario para estos sistemas se migra 
a PCs, y la aplicacion en si misma actua como un servidor y maneja todo el procesamiento de 
la aplicacion y gestion de datos. Un modelo de cliente ligero tambien puede implementarse 
cuando los clientes son dispositivos de red sencillos en lugarde PCs o estaciones de trabajo. 
El dispositivo de red ejecuta un navegador de Internet y la interfaz de usuario es implemen- 
tada a traves de ese sistema. 

Una gran desventaja del modelo de cliente ligero es que ubica una elevada carga de proce- 
samiento tanto en el servidor como en la red. El servidor es responsable de todos los calculos, 
y esto puede implicar la generacion de un trafico significativo en la red entre el cliente y el ser- 
vidor. Los dispositivos de computacion modernos disponen de una gran cantidad de potencia 
de procesamiento, la cual es bastante poco usada en la aproximacion de cliente ligero. 

El modelo de cliente rico hace uso de esta potencia de procesamiento disponible y distri- 
buye tanto el procesamiento de la logica de la aplicacion como la presentacion al cliente. El 
servidor es esencialmente un servidor de transacciones que gestiona todas las transacciones 
de la base de datos. Un ejemplo de este tipo de arquitectura es la de los sistemas bancarios 
A T M , en donde cada A T M es un cliente y el servidor es un mainframe que procesa la cuenta 
del cliente en la base de datos. El hardware de los cajeros automaticos realiza una gran can- 
tidad de procesamiento relacionado con el cliente y asociado a la transaccion. 

Este sistema distribuido ATM se ilustraenlaFigura 12.6. Observe que los ATMs no seco- 
nectan directamente con la base de datos de clientes sino con un monitor de teleproceso. Un 
monitor de teleproceso o gestor de transacciones es un sistema middleware que organiza las 
comunicaciones con los clientes remotos y serializa las transacciones de los clientes para su 
procesamiento en la base de datos. El uso de transacciones serializadas significa que el siste- 
ma puede recuperarse de los defectos sin corromper los datos del sistema. 

Aunque el modelo de cliente rico distribuye el procesamiento de forma mas efectiva que 
un modelo de cliente ligero, la gestion del sistema es mas compleja. La funcionalidad de la 
aplicacion se expande entre varias computadoras. Cuando la aplicacion software tiene que ser 
modificada, esto implica la reinstalacion en cada computadora cliente. Esto puede significar 
un coste importante si hay cientos de clientes en el sistema. 
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La aparicion del codigo movil (como los applets de Java y los controles Active X), que 
pueden descargarse en un cliente desde un servidor, ha permitido el desarrollo de sistemas 
cliente-servidor que son algo intermedio entre los modelos de cliente ligero y rico. Algunas 
de las aplicaciones de procesamiento de software pueden descargarse en el cliente como co- 
digo movil, aligerando asi la carga en el servidor. La interfaz de usuario se crea usando un 
navegador web que incluye utilidades de construccion de programas para ejecutar el codigo 
descargado. 

El problema con una aproximacion cliente-servidor de dos capas es que las tres capas 16- 

gicas presentacion procesamiento de la aplicacion y gestion de los datos — deben asociar- 

se con dos computadoras el cliente y el servidor. Aqui puede haber problemas con la escala- 
bilidad y rendimiento si se elige el modelo de cliente ligero, o problemas con la gestion del 
sistema si se usa el modelo de cliente rico. Para evitar estos problemas, una aproximacion al- 
ternativa es usar una arquitectura cliente-servidor de tres capas (Figura 12.7). En esta arqui- 
tectura, la presentacion, el procesamiento de la aplicacion y la gestion de los datos son pro- 
cesos logicamente separados que se ejecutan sobre procesadores diferentes. 

Un sistema bancario por Internet (Figura 12.8) es un ejemplo de una arquitectura cliente- 
servidor de tres capas. La base de datos de clientes del banco (usualmente ubicada sobre una 
computadora mainframe) proporciona servicios de gestion de datos; un servidor web propor- 
ciona los servicios de aplicacion tales como facilidades para transferir efectivo, generar esta- 
dos de cuenta, pagar facturas, y asi sucesivamente; y la propia computadora del usuario con 
un navegador de Internet es el cliente. El sistema es escalable debido a que es relativamente 
facil anadir nuevos servidores web a medida que el numero de clientes crece. 

El uso de una arquitectura de tres capas en este caso permite optimizar la transferen- 
cia de informacion entre el servidor web y el servidor de la base de datos. Las comunica- 
ciones entre estos sistemas pueden usarprotocolos de comunicacion de bajo nivel muy ra- 
pidos. Para manejar la recuperacion de informacion de la base de datos se utiliza un 
middleware eficiente que soporte consultas a la base de datos en SQL (Stmctured Query 
Language). 
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Arquitectura C/S de dos 
capas can clientes Ngeros 



Arquitectura C/S de dos 
capas con clientes ricos 



Arquitectura C/S de tres 
capas o multicapa 



Aplicaciones de sistemas heredados en donde no es practice separar e! procesamiento de la 
aplicaddn y la gestion de los datos. 

Aplicaciones que requieren calculos intensivos tales como compiladores con poca o ningu- 
na gestidn de los datos. 

Aplicaciones que requieran manejar una gran cantidad de datos (navegar y consurtar) con 
poco o ningiin procesamiento de la aplicaci6n. 

Aplicaciones en donde el procesamiento de la aplicacibn se proporciona por software co 
mercial (por ejemplo, Microsoft Excel) sobre el cliente. 

Aplicaciones que requieren un procesamiento de datos computacionalmente intensivo (por 
ejemplo, visualization de datos). 

Aplicaciones con una funcionalidad para el usuario final relativamente estable usada en un 
entomo de gestidn del sistema bien establecido. 

Aplicaciones a gran escala con cientos o miles de clientes. 
Aplicaciones en donde tarrto los datos como la aplicacion son volatile*. 
Aplicaciones en donde se integran datos de multiples fuentes. 



Figura 12.9 Uso de diferentes arquitecturas cliente-servidor. 



En algunos casos resulta adecuado extender el modelo cliente-servidor de tres capas a 
una variante multicapa en la que se afladen al sistema servidores adicionales. Los sistemas 
multicapa pueden usarse cuando las aplicaciones necesitan acceder y usar datos de dife- 
rentes bases de datos. En este caso, un servidor de integracion se ubica entre el servidor de 
aplicaciones y los servidores de la base de datos. El servidor de integracion recoge los da- 
tos distribuidos y los presenta a la aplicacion como si se obtuviesen desde una unica base 
de datos. 

Las arquitecturas cliente-servidor de tres capas y las variantes multicapa que distribuyen 
el procesamiento de la aplicacion entre varios servidores son intrinsecamente mas escalables 
que las arquitecturas de dos capas. El trafico de la red se reduce al contrario que con las ar- 
quitecturas de dos capas de cliente ligero. El procesamiento de la aplicacion es la parte mas 
volatil del sistema, y puede ser facilmente actualizada debido a que esta localizada central- 
mente. El procesamiento, en algunos casos, puede distribuirse entre la logica de la aplicacion 
y los servidores de gestion de datos, en cuyo caso permite una respuesta mas rapida a las pe- 
ticiones de los clientes. 

Los disefladores de las arquitecturas cliente-servidor deben tener en cuenta una serie de 
factores cuando eligen la arquitectura mas adecuada. En la Figura 12.9 se muestran las situa- 
ciones en las cuales las arquitecturas cliente-servidor analizadas aqui son probablemente las 
mas adecuadas. 



12.3 Arquitecturas de objetos distribuidos 

En el modelo cliente-servidor de un sistema distribuido, los clientes y los servidores son di- 
ferentes. Los clientes reciben servicios de los servidores y no de otros clientes; los servidores 
pueden actuarcomo clientes recibiendo servicios de otros servidores, pero sin solicitar servi- 
cios de clientes; los clientes deben conocer los servicios que ofrece cada uno de los servido- 
res y deben conocer como contactar con cada uno de estos servidores. 

Este modelo funciona bien para muchos tipos de aplicaciones. Sin embargo, limita la fle- 
xibilidadde los disefladores del sistema ya que ellos deben decidir donde se proporciona cada 
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servicio. Tambien deben planificar la escalabilidad y proporcionar algun medio para distribuir 
la carga sobre los servidores cuando mas clientes se afiadan al sistema. 

Una aproximacion mas general al disefto de sistemas distribuidos es eliminar la distincion 
entre cliente y servidor y disenar la arquitectura del sistema como una arquitectura de obje- 
tos distribuidos. En una arquitectura de objetos distribuidos (Figura 12.10), los componentes 
fundamentales del sistema son objetos que proporcionan una interfaz a un conjunto de servi- 
cios que ellos suministran. Otros objetos realizan llamadas a estos servicios sin hacer ningu- 
na distincion logica entre un cliente (el receptor de un servicio) y un servidor (el proveedor 
de un servicio). 

Los objetos pueden distribuirse a traves de varias computadoras en una red y comunicar- 
se a traves de middleware. A este middleware se lo denomina intermediario de peticiones de 
objetos. Su mision es proporcionar una interfaz transparente entre los objetos. Proporciona un 
conjunto de servicios que permiten la comunicacion entre los objetos y que estos sean anadi- 
dos y eliminados del sistema. En la Seccion 12.3.1 se tratan los intermediarios de peticiones 
de objetos. 

Las ventajas del modelo de objetos distribuido son las siguientes: 

• Permite al disenador del sistema retrasar decisiones sobre donde y como deberian pro- 
porcionarse los servicios. Los objetos que proporcionan servicios pueden ejecutarse so- 
bre cualquier nodo de la red. Por lo tanto, la distincion entre los modelos de cliente rico 
y ligero es irrelevante, ya que no hay necesidad de decidir con antelacion donde se situa 
la logica de aplicacion de los objetos. 

• Es una arquitectura de sistema muy abierta que permite anadir nuevos recursos si es ne- 
cesario. Como se indica en la siguiente seccion, se han desarrollado e implementado es- 
tandares de comunicacion de objetos que permiten escribir objetos en diferentes len- 
guajes de programacion para comunicarse y proporcionar servicios entre ellos. 

• El sistema es flexible y escalable. Se pueden crear diferentes instancias del sistema 
proporcionando los mismos servicios por objetos diferentes o por objetos reproduci- 
dos para hacer frente a las diferentes cargas del sistema. Pueden anadirse nuevos ob- 
jetos a medida que la carga del sistema se incrementa sin afectar al resto de los obje- 
tos del sistema. 

• Si es necesario, es posible reconfigurar el sistema de forma dinamica mediante la mi- 
gracion de objetos a traves de la red. Esto puede ser importante donde haya fluctuacion 
en los patrones de demanda de servicios. Un objeto que proporciona servicios puede mi- 
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grar ai mismo procesador que los objetos que demandan los servicios, en lo que mejora 
el rendimiento del sistema. 

Una arquitectura de objetos distribuidos puede ser usada como un modelo logico que per- 
mita estructurary organizar el sistema. En este caso se debe pensar en como proporcionar las 
funcionalidades de la aplicacion unicamente en terminos de servicios y combinaciones de ser- 
vicios. Acontinuacion sedebe identificar como proporcionar estos servicios utilizando varios 
objetos distribuidos. En este nivel, los objetos que se disenan son normalmente de grano grue- 
so (denominados algunas veces objetos de negocio) que proporcionan servicios especificos 
del dominio. Por ejemplo, en una aplicacion de venta al por menor, puede haber objetos de 
negocio relacionados con el control de existencias, comunicaciones con el cliente, pedidos de 
productos y otros. Por supuesto, este modelo logico puede llevarse a cabo como un modelo 
de implementacion. 

De forma alternativa, se puede usar una aproximacion de objetos distribuidos para imple- 
mentar sistemas cliente-servidor. En este caso, el modelo logico del sistema es un modelo 
cliente-servidor, pero tanto los clientes como los servidores se implementan como objetos dis- 
tribuidos que se comunican a traves de un bus software. Esto hace posible realizar cambios 
en el sistema de forma sencilla, por ejemplo, desde un sistema de dos capas a un sistema mul- 
ticapa. En este caso, el servidor o el cliente puede no implementarse como un unico objeto 
distribuido, sino que puede estar compuesto por objetos mas pequenos que proporcionan ser- 
vicios especializados. 

Un ejemplo de un tipo de sistema en el que una arquitectura de objetos distribuidos podria 
ser adecuada es un sistema de mineria de datos que busca relaciones entre los datos almace- 
nados en varias bases de datos (Figura 12.1 1). Un ejemplo de aplicacion de mineria de datos 
podria serun negocio de venta al por menor que tuviese, por ejemplo, tiendas de comestibles 
y tiendas de ferreteria, y quisiera encontrar las relaciones entre compras de diversos tipos de 
comestibles y de ferreteria. Por ejemplo, la gente que quiera comprar comida para bebe tam- 
bien puede comprar un tipo concreto de papel para las paredes. Con este conocimiento, la em- 
presa podria entonces ofrecer ofertas especificas a los clientes de comida para bebe combi- 
nables con otras. 

En este ejemplo, cada base de datos puede encapsularse como un objeto distribuido con 
una interfaz que proporciona acceso de solo lectura a sus datos. Los objetos integradores se 
ocupan cada uno de ellos de tipos especificos de relaciones, y recogen informacion desde to- 
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das las bases de datos para intentar deducir dichas relaciones. Podria haber un objeto inte- 
grador que se ocupara de las variaciones de ventas de comestibles de temporada y otro que se 
ocupara de las relaciones entre los diferentes tipos de comestibles. 

Los objetos visualizadores interaccionan con los objetos integradores para producir una vi - 
sual izacion o un informe de las relaciones descubiertas. Debido a que se manejan grandes vo- 
lumenes de datos, los objetos visualizadores usaran normalmente representaciones graficas de 
las relaciones que hayan descubierto. Se aborda la presentacion de la informacion grafica en 
el Capitulo 16. 

Una arquitectura de objetos distribuidos es adecuada para este tipo de aplicacion en lugar 
de una aplicacion cliente-servidorportresrazones: 

1. A diferencia de un sistema bancario A T M (por ejemplo), el modelo logico del siste- 
ma no es el de provision de servicios en el que se pueden distinguir servicios de ges- 
tion de datos. 

2. Se pueden anadir bases de datos al sistema sin mayor problema. Cada base de datos 
es simplemente otro objeto distribuido. Los objetos de bases de datos pueden propor- 
cionaruna interfaz simplificada que controle el acceso a los datos. Las bases de datos 
a las que se puede acceder pueden residir en diferentes maquinas. 

3. Permite explorar nuevos tipos de relaciones anadiendo nuevos objetos integradores. 
Las partes del negocio que esten interesadas en relaciones especificas pueden exten- 
der el sistema anadiendo objetos integradores que operen sobre sus computadoras sin 
requerir conocimiento de ningun otro integrador que se use en cualquier otra parte del 
sistema. 

La principal desventaja de las arquitecturas de objetos distribuidos es que son mucho mas 
complejas de disenarque los sistemas cliente-servidor. Los sistemas cliente-servidorparecen 
ser la forma mas natural de concebir a los sistemas. Estos reflejan muchas transacciones hu- 
manas en las que la gente solicita y recibe servicios de otra gente especializada en propor- 
cionar dichos servicios. Es mas dificil pensar en una provision de servicios generates, y to- 
davia no tenemos una gran experiencia en el diseno y desarrollo de objetos de negocio de 
grano grueso. 

12.3.1 CORBA 

Tal y como se ha indicado en la seccion previa, la implementacion de una arquitectura de ob- 
jetos distribuidos requiere un middleware (intermediaries de peticiones de objetos) para ges- 
tionar las comunicaciones entre los objetos distribuidos. En principio, los objetos en el siste- 
ma pueden implementarse utilizando diferentes lenguajes de programacion, los objetos 
pueden ejecutarse sobre diferentes plataformas y sus nombres no necesitan serconocidos por 
el resto de los objetos del sistema. Por lo tanto, el «pegamento» middleware tiene que reali- 
zar mucho trabajo para asegurar la transparencia en las comunicaciones de los objetos. 

Se requiere middleware a dos niveles para soportar la computacion de objetos distribuidos: 

1. A nivel de comunicacion logica, el middleware proporciona funcionalidades que per- 
miten a los objetos intercambiar datos y controlar la informacion sobre diferentes com- 
putadoras. Se han desarrollado estandares como CORBA y COM (Pritchard, 1999) 
para facilitar las comunicaciones logicas de objetos sobre diferentes plataformas. 

2. A nivel de componentes, el middleware proporciona una base para desarrollar com- 
ponentes compatibles. Estandares tales como componentes CORBA, EJB o Active X 
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(Szyperski, 2002) proporcionan una base para la implementacion de componentes 
con metodos estandar que pueden requerirse y usarse por otros componentes. Co- 
mentamos los estandares de componentes en el Capitulo 19. 

En esta seccion, se trata el middleware para comunicaciones logicas de objetos y se ex- 
plica como se soporta esto por los estandares CORBA. Estos estandares fueron definidos 
por el Ohject Management Group (OMG), que define los estandares para el desarrollo 
orientado a objetos. Los estandares O MG estan disponibles, de forma gratuita, desde su si- 
tio web. 

La vision de OMG de una aplicacion distribuida se muestra en la Figura 12.12, que se ha 
adaptado del diagrama de Siegel de la Ohject Management Architectura (Siegel, 1998). Esta 
propone que una aplicacion distribuida deberia estar formada por varios componentes: 

1. Objetos de aplicacion disefiados e implementados para esta aplicacion. 

2. Objetos estandar definidos por el OMG para un dominio especifico. Estos estandares 
para objetos del dominio incluyen areas como financieras/aseguradoras, comercio 
electronico y medicas. 

3. Los servicios fundamentales CORBA. que proporcionan servicios de computacion 
distribuida tales como gestion de seguridad y directories. 

4. Facilidades CORBA horizontales tales como facilidades de interfaz de usuario, faci- 
lidades para gestion del sistema, y otras. La denominacion/aciYiVtafes horizontales su- 
giere que estas facilidades son comunes a muchos dominios de aplicacion y, por lo tan- 
to, se usan en muchas aplicaciones diferentes. 

Los estandares CORBA incluyen todos los aspectos de esta vision. Hay cuatro elementos 
principales para estos estandares : 

1 . Un modelo de objetos para objetos de aplicacion en donde un objeto C O RB A es una 
encapsulacion de un estado con una interfaz con un lenguaje neutral y bien definido 
descrito en IDL (Interface Definition Language). 

2. Un intermediario de peticiones de objetos (ORB) que gestiona peticiones para servi- 
cios de objetos. Este ORB localiza al objeto que proporciona el servicio, lo prepara 
paralapeticion, envia lapeticion de servicio y devuelve el resultado al solicitante del 
servicio. 

3. Un conjunto de servicios de objetos que son servicios generales que probablemente se- 
ran requeridos por muchas aplicaciones distribuidas. Ejemplos de servicios son servi- 
cios de directorio, servicios de transacciones y servicios de persistencia. 
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4. Un conjunto de componentes commies construidos sobre estos servicios basicos que 
pueden ser requeridos por las aplicaciones. Pueden ser componentes verticales espe- 
cificos del dominio o componentes horizontales de proposito general usados por mu- 
chas aplicaciones. 

El modelo de objetos CORB A consideraque un objeto esuna encapsulacionde atributos 
y servicios, como ocurre con los objetos normales. Sin embargo, los objetos CORB A deben 
tener una definicion de la interfaz separada que defina los atributos y operaciones publicas del 
objeto. Las interfaces de objetos CORB A se definen utilizando un lenguaje de definicion de 
interfaces estandar independiente del lenguaje. Si un objeto desea usar los servicios propor- 
cionados por otro objeto, entonces accede a dichos servicios a traves de la interfaz IDL . Los 
objetos C O RB A tienen un unico identificador denominado referencia de objeto interoperable 
(1 OR). Este IOR se usa cuando un objeto solicita los servicios de otro. 

El intermediario de peticiones de objeto conoce a los objetos que estan solicitando servi- 
cios y a sus interfaces. El ORB gestiona la comunicacion entre los objetos. Los objetos que 
se comunican no necesitan conocer la localizacion de otros objetos ni necesitan conocer nada 
acerca de su implementacion. Como la interfaz IDL aisla los objetos del ORB , es posible cam- 
biar la implementacion del objeto de una forma completamente transparente. La localizacion 
del objeto puede cambiar entre las invocaciones, lo cual es transparente para el resto de los 
objetos del sistema. 

Por ejemplo, en la Figura 12.13, dos objetos ol y 02 se comunican a traves de un ORB . 
El objeto que hace la llamada (ol) tiene un stub IDL asociado que define la interfaz del ob- 
jeto que proporciona el servicio solicitado. El implementador de ol incluye la llamada a este 
stub en su implementacion del objeto cuando se solicita un servicio. El IDL es un supercon- 
junto de C++; por lo tanto, es muy facil acceder a este stub si se esta programando en C++, y 
es igualmente facil hacerlo en C o Java. Las correspondencias entre otros lenguajes e IDL tam- 
bien han sido definidas para lenguajes como, por ejemplo, ADAyCOBOL. 

El objeto que proporciona el servicio tiene un sketewn IDL asociado que enlaza la inter- 
faz con la implementacion de los servicios. En terminos simples, cuando un servicio se llama 
a traves de la interfaz, el skeleton IDL traduce esta peticion en una llamada al servicio al len- 
guaje de implementacion que se haya utilizado. Cuando el metodo o procedimiento sea eje- 
cutado, el skeleton IDL traduce los resultados a IDL para que puedan ser accedidos por el ob- 
jeto que realizo la llamada. Cuando un objeto proporciona servicios a otros objetos y tambien 
usa los servicios proporcionados en alguna parte, necesita ambos, un skeleton y un stub IDL. 
Se requiere un stub IDL para cada objeto que sea usado. 

Los intermediaries de peticiones de objetos no se implementan normalmente como proce- 
sos separados, pero son un conjunto de librerias que pueden enlazarse con las implementa- 
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ciones de los objetos. Por lo tanto, en un sistema distribuido, cada computadora que esta eje- 
cutando objetos distribuidos tendra su propio intermediario de peticiones de objetos. Este ma- 
nejara todas las invocaciones locales de objetos. Sin embargo, una peticion de un servicio pro- 
porcionado porun objeto remoto requiere comunicaciones inter-ORB. 

Esta situacion se ilustra en la Figura 12.14. En este ejemplo, cuando el objeto o 1 u o2 so- 
licitanun servicio de o3 o de o4. los ORBs asociados deben comunicarse. Una implementa- 
cion CORBA soporta comunicacion ORB-a-ORB siempre que se proporcione a todos los 
ORBs el acceso a las definiciones de la interfaz IDL y ademas estos implementen los estan- 
dares de O M G denominados Protocolo Generico Inter-ORB (GIOP). Este protocolo define 
mensajes estandar que los ORBs pueden intercambiar para implementar llamadas a objetos 
remotos y transferir informacion. Cuando GIOP se combina con los protocolos de Internet 
TCP/IP, el GIOP permite a los ORBs comunicarse a traves de Internet. 

La iniciativa C O RB A ha estado presente desde los anos 80, y las primeras versiones de 
CORBA simplemente pretendian dar soporte a los objetos distribuidos. Sin embargo, a me- 
dida que los estandares han evolucionado, se han ido extendiendo cada vez mas. Ademas de 
un mecanismo para comunicaciones de objetos distribuidos, los estandares CORBA definen 
actualmente algunos servicios estandar que pueden proporcionarse para soportar aplicaciones 
orientadas a objetos distribuidos. 

Se puede pensar en los servicios CORBA como facilidades que probablemente sean re- 
queridas pormuchos sistemas distribuidos. Los estandares definen aproximadamente 15 ser- 
vicios comunes. Algunos ejemplosde estos servicios genericos son: 

1. Servicios de nombres y de categorias {trading) que permiten a los objetos hacer refe- 
renda y encontrar a otros objetos de la red. El servicio de nombres es un servicio de 
directorios que permite a los objetos asignar nombres a otros objetos y encontrarlos. 
Esto es similar a las paginas blancas de un listin telefonico. Los servicios trading son 
como las paginas amarillas. Los objelos pueden encontrar a otros objetos que se ha- 
yan registrado con este servicio y acceder a la especificacion de dichos objetos. 

2. Servicios de notificacion que permiten a los objetos notificar a otros objetos que ha 
ocurrido algun evento. Los objetos pueden registrar su interes en un evento especi- 
fico del servicio y, cuando el evento ocurre, este se les notifica automaticamente. Por 
ejemplo, supongamos que el sistema incluye una cola de impresion que encola do- 
cumentos para ser impresos y a varios objetos impresora. La cola de impresion re- 
gistra que esta interesada en un evento de «final de impresion» de un objeto impre- 
sora. El servicio de notificacion informa al objeto interesado cuando la impresion se 
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completa. A continuacion este puede programar el siguiente documento sobre esa 
impresora. 

3. Serviciosde transacciones que soportan transacciones atomic as yoperaciones rollback 
cuando ocurre un fallo. Las transacciones son una facilidad tolerante a defectos que 
soportan la recuperacion de errores durante una operacion de actualizacion. Si una 
operacion de actualizacion de un objeto falla, entonces el estado del objeto puede vol- 
ver a su estado anterior a la actualizacion (operacion roltback). 

Los estandares CORBA incluyen definiciones de interfaz para un amplio rango de com- 
ponentes horizontales y verticales que pueden usarse por los constructores de aplicaciones dis- 
tribuidas. Los componentes verticales son componentes especificos paraun dominio de apli- 
cacion. Los componentes horizontales son componentes de proposito general como los 
componentes de interfaz de usuario. El desarrollo de especificaciones para componentes 
CORBA horizontales y verticales es una actividad a largo plazo, y las especificaciones dis- 
ponibles actualmente son publicadas en el sitio web de O M G . 

12.4 Computacion distribuida interorganizacional 

Por razones de seguridad e interoperabilidad, la computacion distribuida ha sido principal- 
mente implementada a nivel organizacional. Una organizacion tiene varios servidores y re- 
parte su carga computacional entre ellos. Debido a que dichos servidores estan todos dentro 
de la misma organizacion, pueden aplicarse estandares locales y procesos operacionales. Aun- 
que, para los sistemas basados en web, las computadoras cliente estan a menudo fuera de los 
limites de la organizacion, su funcionalidad esta limitada a la ejecucion de software de inter- 
faz de usuario. 

Sin embargo, actualmente estan disponibles modelos mas recientes de computacion dis- 
tribuida que permiten computacion distribuida interorganizacional en lugar de intraorganiza- 
cional. Comentamos dos de estas aproximaciones en esta seccion. La computacion peer-to- 
peer se basa en calculos que se llevan a cabo en nodos individuates de la red. Los sistemas 
orientados a servicios estan relacionados con los servicios distribuidos en lugar de con obje- 
tos distribuidos, y tambien se relacionan con estandares basados en X M L para intercambio de 
datos. 

12.4.1 Arquitecturas peer-to-peer 

Los sistemas peer-to-peer (p2p) son sistemas descentralizados en los que los calculos pueden 
llevarse a cabo en cualquier nodo de la red y, al menos en principio, no se hacen distinciones 
entre clientes y servidores. En las aplicaciones peer-to-peer, el sistema en su totalidad se di- 
sena para aprovechar la ventaja de la potencia computacional y disponibilidad de almacena- 
miento a traves de una red de computadoras potencialmente enorme. Los estandares y proto- 
colos que posibilitan las comunicaciones a traves de los nodos estan embebidos en la propia 
aplicacion, y cadanodo debe ejecutaruna copiade dicha aplicacion. 

En el momento de escribir este libro, las tecnologias peer-to-peer han sido mayormente 
usadas para sistemas personales (Oram, 2001). Porejemplo, los sistemas de comparticion de 
ficheros basados en losprotocolos Gnutella y Kazaa seusanparacompartir ficheros sobre PCs 
de usuario, y sistemas de mensajeria instantanea tales como ICQ y Jabber proporcionan co- 
municaciones directas entre usuarios sin un servidor intermedio. SETI@home es un proyec- 
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to a largo plazo para procesar datos de radiotelescopios sobre PCs desde casa para buscar in- 
dicios de vida extraterrestre, y Freenet es una base de datos descentralizada que ha sido dise- 
nada para hacer mas facil la publicacion de informacion de forma anonima y hacer que sea 
mas dificil para las autoridades suprimir esta informacion. 

Sin embargo, hay indicios de que esta tecnologia se estautilizando de forma creciente en 
empresas para que las redes de PCs soporten la potencia de dichas empresas (McDougall, 
2000). Intel y Boeing han implementado sistemas p2p para aplicaciones que requieren com- 
putaciones intensivas. Para aplicaciones cooperativas que soportan trabajo distribuido, estapa- 
rece ser la tecnologia mas efectiva. 

Usted puede ver la arquitectura de las aplicaciones p2p desde dos puntos de vista. La ar- 
quitectura logica de la red es la distribucion de la arquitectura del sistema, mientras que la ar- 
quitectura de la aplicacion es la organizacion generica de los componentes en cada tipo de 
aplicacion. Este capitulo se centra en los dos tipos principales de arquitecturas logicas de red 
que se pueden usar: arquitecturas descentralizadas y arquitecturas semjcentralizadas. 

En principio, en los sistemas peer-to-peer cada nodo en la red podria conocer cualquier otro 
nodo, podria conectarse con el, y podria intercambiar datos. En lapractica, por supuesto, esto 
es imposible, ya que los nodos se organizan dentro de «localidades» con algunos nodos que 
actuan como puentes a otras localidades de nodos. La Figura 12.15 muestra esta arquitectura 
p2p descentralizada. 

En una arquitectura descentralizada, los nodos en la red no son simplemente elementos 
funcionales, sino que tambien son interraptores de comunicaciones que pueden encaminar los 
datos y senales de control de un nodo a otro. Por ejemplo, supongamos que la Figura 12.15 
representa un sistema de gestion de documentos descentralizado. El sistema es usado por un 
consorcio de investigadores para compartir documentos, y cada miembro del consorcio man- 
tiene su propio almacen de documentos. Sin embargo, cuando un documento es recuperado, 
el nodo que recupera ese documento tambien lo hace disponible para los otros nodos. Cual- 
quiera que necesite un documento genera un comando de busqueda que es enviado a los no- 
dos de esa «localidad». Estos nodos comprueban si tienen el documento y, si es asi, lo de- 
vuelven al que ha hecho la peticion. Si dichos nodos no tienen el documento, encaminan la 
busqueda a otros nodos; cuando finalmente se encuentra el documento, el nodo puede enca- 
minarlo de vueltaal nodo original que hizo la peticion. Porlo tanto, si n 1 emiteunabusque- 
da de un documento que esta almacenado en n 10, esta busqueda se encamina a traves de los 
nodos n3, n6 y n9 hasta llegar a niO. 




Figura 12.15 Arquitectura p2p descentralizada. 
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Figura 12.16 Una 

arquitectura p2p 
semicentralizada. 
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Esta arquitectura descentralizada tiene ventajas obvias en tanto que es altamente redun- 
dante, y por lo tanto es tolerante a defectos y tolerante a nodos desconectados de la red. Sin 
embargo, existen sobrecargas obvias en el sistema ya que la misma busqueda puede serpro- 
cesada por muchos nodos diferentes y hay una sobrecarga significativa en comunicaciones en- 
tre iguales replicadas. Un modelo de arquitectura p2p alternativo que parte de una arquitec- 
tura p2p pura es una arquitectura semicentralizada en la que, dentro de la red, uno o mas nodos 
actuan como servidores para facilitar las comunicaciones entre los nodos. La Figura 12.16 
ilustra este modelo. 

En una arquitectura semicentralizada, el papel del servidor es ayudar a establecer contac- 
to entre iguales en la red o para coordinar los resultados de un calculo. Por ejemplo, si la Fi- 
gura 12.16 representa un sistema de mensajeria instantanea, entonces los nodos de la red se 
comunican con el servidor (indicado por lineas discontinuas), para encontrar que otros nodos 
estan disponibles. Una vez que estos son encontrados, se pueden establecer comunicaciones 
directas y la conexion con el servidor es innecesaria. Por lo tanto, los nodos n2, n3, n5 y n6 
estan en comunicacion directa. 

En un sistema computacional p2p en donde un calculo que requiere un uso intensivo del 
procesador se distribuye a traves de un gran numero de nodos, es normal que se distingan al- 
gunos nodos cuyo papel es distribuir el trabajo a otros nodos y reunir y comprobar los resul- 
tados del calculo. 

Si bien hay sobrecargas obvias en los sistemas peer-to-peer, estos son una aproximacion 
mucho mas eficiente para lacomputacion interorganizacional que la aproximacion basada en 
servicios que se comentan en la siguiente seccion. Todavia hay problemas en el uso de las 
aproximaciones p2p para computacion interorganizacional, ya que cuestiones tales como pro- 
teccion y autenticidad siguen todavia sin resolverse. Esto significa que los sistemas p2p son 
mas probables de usar en sistemas de informacion no criticos o bien cuando ya existen rela- 
ciones de trabajo entre las organizaciones. 

Arquitectura de sistemas orientados a servicios 

El desarrollo de la W W W trajo consigo que las computadoras cliente tuviesen acceso a los 
servidores remotos situados fuera de sus propias organizaciones. Si estas organizaciones con- 
vertian su informacion a formato HTML, entonces esta podia ser accedida por estas compu- 
tadoras. Sin embargo, el acceso se realizaba solamente a traves de un navegador web. y el ac- 
ceso directo a los almacenes de informacion por otros programas no era practico. Esto 
implicaba que las conexiones oportunistas entre servidores en donde, por ejemplo, un pro- 
grama solicitaba informacion a varioscatalogos, no eranposibles. 
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Para solucionar este problema, se propuso la nocion de un servicio web. Mediante el uso 
de un servicio web, las organizaciones que quieren hacer accesible la informacion a otros pro- 
gramas, pueden hacerlo definiendo y publicando una interfaz de servicio web. Esta interfaz 
define los datos disponibles y como se puede acceder a ellos. De forma mas general, un ser- 
vicio web es una representacion estandarpara cualquier recurso computacional o de infor- 
macion que pueda ser usado por otros programas. Por lo tanto, se podria definir un servicio 
de recaudacion de impuestos en el que los usuarios podrian rellenar sus formularios de im- 
puestos y estos ser automaticamente comprobados y enviados a las autoridades de hacienda. 

Un servicio web es una instancia de una nocion mas general de un servicio, la cual se de- 
fine en (Lovelock et al., 1996) como: 

un acto o realization ofertada por una de las partes a otra. SIbien el proceso puede 
estar asoclado a un producto fisico, la realization es esencialmenie intangible, vnose 
convierte normalmente en propietaria de cualquiera de los factores de la production. 

La esencia de un servicio, por lo tanto, es que la provision de servicio es independiente de 
la aplicacion que usa el servicio (Turner et al.. 2003). Los proveedores de servicios pueden 
desarrollar servicios especializados y ofertarlos a un cierto numero de usuarios de servicios 
desde diferentes organizaciones. Las aplicaciones pueden construirse enlazando los servicios 
desde varios proveedores utilizando bien un lenguaje de programacion estandaro bien un len- 
guajede instrumentacionde servicios talcomo BPEL4 WS . 

Existen varios modelos de servicios, desde el modelo JINI (Kumaran, 2001) pasando por 
los servicios web (Stal, 2002) y servicios de rejilla (Foster et al., 2002). Conceptualmente, to- 
das ellos operan de acuerdo con el modelo mostrado en la Figura 12.17, la cual es una gene- 
ralizacion del modelo conceptual de servicios web descrito por Kreger (Kreger, 2001). Un 
proveedor de servicio oferta un servicio definiendo su interfaz y definiendo la funcionalidad 
del servicio. Un solicitante del servicio enlaza este servicio en su aplicacion. Esto significa 
que la aplicacion del solicitante incluye codigo para llamar al servicio y procesa el resultado 
de la llamada al servicio. Para asegurar que el servicio puede ser accedido por usuarios ex- 
temos a dicho servicio, el proveedor de servicios registra una entrada en el servicio de regis- 
tro que incluye informacion sobre el servicio y lo que hace. 

Las diferencias entre este modelo de servicios y la aproximacion de objetos distribuidos 
para arquitecturas de sistemas distribuidos son las siguientes: 

• Los servicios pueden ofertarse por cualquier proveedor de servicio dentro o fuera de una 
organizacion. Suponiendo que estos cumplen ciertos estandares (analizados mas ade- 
lante), las organizaciones pueden crear aplicaciones integrando servicios desde varios 
proveedores. Porejemplo, un compafna de fabricacion puede enlazar directamente a los 
servicios proporcionados por sus proveedores. 



Figura 12.17 
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• El proveedor de servicios hace publica la informacion sobre el servicio para que cual- 
quier usuario autorizado pueda usarlo. El proveedor de servicios y el usuario de los ser- 
vicios no necesitan negociar sobre lo que el servicio hace antes de ser incorporado en un 
programa de aplicacion. 

• Las aplicaciones pueden retrasar el enlace de los servicios hasta que estas sean desple- 
gadas o hasta que esten en ejecucion. Por lo tanto, una aplicacion que usaun servicio de 
precios de productos (por ejemplo) podria cambiar dinamicamente los proveedores de 
los servicios mientras el sistema se esta ejecutando. 

• Es posible la construccion oportunista de nuevos servicios. Un proveedor de servicios 
puede reconocer nuevos servicios que se crean enlazando servicios existentes de formas 
innovadoras. 

• Los usuarios de los servicios pueden pagar por los servicios con arreglo a su uso en vez 
de a su provision. Por lo tanto, en lugar de comprar un componente de precio elevado 
que se usa muy raramente, el desarrollador de la aplicacion puede usar un servicio ex- 
terno por el que pagara solamente cuando sea requerido. 

• Las aplicaciones pueden hacerse mas pequenas (lo cual es importante si tienen que es- 
tar embebidas en otros dispositivos) debido a que pueden implementar el manejo de ex- 
cepciones como servicios externos. 

• Las aplicaciones pueden ser reactivas y adaptar su operacion de acuerdo con su entorno 
enlazando con diferentes servicios a medida que cambia este. 

En el momento de escribireste libro, estas ventajas han suscitado un gran interes en los ser- 
vicios web como base para la construccion de aplicaciones distribuidas debilmente acopladas. 
Sin embargo, la experiencia practica con las arquitecturas orientadas a servicios todavia es 1 i- 
mitada, por lo que aun no conocemos las implicaciones practicas de esta aproximacion. 

La reutilizacion del software ha sido un tema de investigacion durante muchos anos; to- 
davia, tal y como se indica en los Capitulos 1 8 y 19, quedan pendientes muchas dificultades 
practicas en la reutilizacion del software. Uno de los principales problemas ha sido que los 
estandares para componentes reutilizables han sido desarrollados hace relativamente poco 
tiempo, y varios de estos estandares estan en uso. Sin embargo, la iniciativa de los servicios 
web ha estado guiada por estandares desde su nacimiento, y los estandares que incluyen mu- 
chos aspectos de los servicios web estan desarrollandose. Los tres estandares fundamentales 
que permiten la comunicacion entre servicios web son: 

1. SOAP (Simple Object Access Protocol). Este protocolo define una organizacion para 
intercambio de datos estracturados entre servicios web. 

2. WSDL (Web Services Description Language). Este protocolo define como pueden re- 
presentarse las interfaces de servicios web. 

3. UDDl (Universal Description, Discovery and integration). Este es un estandar de 
busqueda que define como puede organizarse la informacion de descripcion de servi- 
cios, usada por los solicitantes de los servicios para encontrar servicios. 

Todos estos estandares se basan en X M L , un lenguaje legible por los humanos y las ma- 
quinas (Skonnard y Gudgin, 2002). Sin embargo, no es necesario conocer detalles de estos es- 
tandares para comprender el concepto de servicios web. 

Las arquitecturas de aplicaciones de servicios web son arquitecturas debilmente acopladas 
en donde el enlace a los servicios puede cambiar durante la ejecucion. Algunos sistemas se 
construiran solamente usando servicios web y otros mezclaran servicios web desarrollados lo- 
calmente. Para ilustrar como pueden organizarse las aplicaciones, considere la siguiente si- 
tuacion: 
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Un sistema de information en un vehiculo proporciona dispositivos con information 
sobre el tiempo, condiciones del trdfico de carretera, information ;ocal y otras. Este 
se enlaza con la radio del vehiculo para que la information sea proporcionada conto 
una sehal sobre un canal de radio especifico. El vehiculo es equipado con un receptor 
de GPS para descubrir su position v, basdndose en esa position, el sistema accede a 
un cierto numero de servicios de information. La information puede proporcionarse 
en el lenguaje especiflcado del dispositivo. 

La Figura 12.18 ilustra una posible organizacion para el sistema anterior. El software de! 
vehiculo incluye cinco modulos. Estos gestionan las comunicaciones con el dispositivo, con 
un receptor GPS que informa de la posicion del vehiculo y con la radio del vehiculo. Los mo- 
dulos Transmisor y Receptor gestionan todas las comunicaciones con los servicios externos. 

El vehiculo se comunica con un servicio de informacion movil proporcionado extema- 
mente que aflade informacion desde otros servicios que proporcionan informacion sobre el 
tiempo, trafico y facilidades locales. Diferentes proveedores en distintos lugares proporcio- 
nan este servicio, y el sistema software del vehiculo usa un servicio de busqueda para locali- 
zar el servicio de informacion adecuado y enlazar con el. El servicio de busqueda tambien es 
usado por el servicio de informacion movil para enlazar con los servicios adecuados de tiem- 
po, trafico y facilidades. Los servicios intercambian mensajes SOAP que incluyen la infor- 
macion de la posicion GPS usada, para seleccionar la informacion adecuada. La informacion 
anadida se devuelve al vehiculo a traves de un servicio que traduce el lenguaje de informa- 
cion al lenguaje del dispositivo. 
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Este ejemplo ilustraunade las ventajas clave de la aproximacion orientada a servicios. No 
es necesario decidir cuando se programa o despliega el sistema, que suministrador de servi- 
ciodeberiausarsey a que servicios especificos se deberia acceder. A medidaque el vehiculo 
se mueve, el software del vehiculo usa el servicio de busqueda para encontrar el servicio de 
informacionmas adecuadoy enlazarconel. Debido alusodeun servicio de traduccion, la in- 
formacion puede traspasar los limites locales y, por lo tanto, hacer que la informacion local 
este disponible para gente que no hable el lenguaje local. 

Esta vision de computacion orientada a servicios todavia no es realizable con los actuales 
servicios web, en los que el enlazado de servicios a las aplicaciones todavia es bastante esta- 
tico. Sin embargo, antes de que aparezca una nueva edicion de este libro, es probable que haya 
mas enlaces dinamicos y arquitecturas de aplicaciones. No hay duda de que el modelo orien- 
tado a servicios representa una forma nueva muy importante de implementar los sistemas de 
computacion distribuidos interorganizacionales. 
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LECTURAS ADICIONALES 



«Turning software into a service». Un buen articulo que analiza los principios de la computacion orientada a servi- 
cios. A diferencia de muchos articulos sobre este tema, no encubre estos principios con un analisis de los estanda- 
res relacionados. [M. Turner etai., IEEE Computer, 36 (10), octubre 2003.] 

Peerto-Peer. Harnessing the Power of Disruptive Technologies. Aunque este libro no trata en profundidad las ar- 
quitecturas p2p, es una excelente introduccion a la computacion p2p y analiza la organizaciony aproximacion usa- 
das en varios sistemas p2p. [A. Oram (ed.), 2001,0'Reilly and Associates, Inc.] 

Distributed Systems: Concepts and Design, srded. Un libro de texto facil de entender que discute todos los aspec- 
tos del diseno e implementacion de sistemas distribuidos. Los dos primeros capitulos son particularmente rele- 
vantesparael capitulo aqui expuesto. (G. Couloris etai., 2001, Addison- Wesley.) 

«Middleware: A model for distributed systems services)). Este es un excelente articulo que resume el papel del mid- 
dleware en los sistemas distribuidos y examina los distintos servicios middleware que se pueden proporcionar. [P. 
A. Bernstein, Comm. ACM, 39 (2), febrero 1996). 



EJERCICIOS 



121 Explique por que los sistemas distribuidos son intrinsecamente mas escalables que los sistemas centra- 
lizados. ^Cuales son los Limites mas probables de la escalabilidad del sistema? 

122 ^Cual es la diferencia fundamental entre una aproximacion de cliente rico y una de cliente ligero para el 
desarrollo de sistemas cliente-servidor? Explique por que el uso de Java como lenguaje de implementacion 
atenua la diferencia entre estas aproximaciones. 

123 Su cliente quiere desarrollar un sistema para almacenar informacion en donde los distribuidores pueden 
acceder a la informacion de las companias, y pueden evaluar varios escenarios de inversion usando un sis- 
tema de simulacion. Cada distribuidor usa esta simulacion de forma diferente, de acuerdo con su expe- 
riencia y el tipo de almacenes con los que trabaja. Sugiera una arquitectura cliente-servidor para este sis- 
tema que muestre donde se localiza la funcionalidad. Justifique el modelo cliente-servidor que usted ha 
elegido. 

124 Haciendo referencia al modelo de aplicacion mostrado en la Figura 124, comente los problemas que po- 
drian tener lugar al convertirun sistema heredado de la decada de los 80 que utiliza un mainframe para 
procesamiento de polizas de seguros a una arquitectura cliente-servidor. 

125 ^Cuales son las facilidades basicas que puede proporcionar un intermediario de peticiones de objetos? 

126 Explique por que el uso de objetos distribuidos con un intermediario de peticiones de objetos simplifica 
la implementacion de sistemas cliente-servidor escalables. Ilustre su respuesta con un ejemplo. 

127 ^,C6mo seusael IOLdeCORBA para soportarcomunicaciones entre objetos que hansido jmplementados 
en diferentes lenguajes deprogramacion? Explique por que esta aproximacion puede ocasionar problemas 
de rendimiento si hay diferencias sustanciales entre los lenguajes usados para la implementacion de los 
objetos. 
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12.8 Usando una aproximacion de objetos distribuidos, propongauna arquitecturaparaun sistema nacional de 
venta de entradas para teatros en donde los usuarios puedan comprobar la disponibilidad de las locali- 
dades y reservarestas en un grupo de teatros. El sistema deberia soportar devoluciones de entradas para 
que la gente pueda devolver sus entradas y que estas se puedan vender a otros clientes en el ultimo mo- 
menta. 



12.9 



Indique dos ventajas y dos desventajas de las arquitecturas peer-to-peer descentralizadas y semicentrali- 
zadas. 

12.10 ^Cuales son las ventajas del enlace dinamico en un sistema orientado a servicios? 

1211 Para el sistema de informacion del vehiculo, explique por que es mejor que el software del vehiculo se co- 
munique con un servicio global en lugarde hacerlo directamente con servicios de informacion individuales. 

12.12 El desarrollo de la computacion orientada a servicios se ha basado en la especificacion y adopcion tem- 
prana de estandares. Coemente el papel general de la estandarizacion para soportar y restringir la com- 
peticion e innovacion en el mercado del software. 



Arquitecturas 
aplicaciones 

Objetivos 

El objetivo de este capitulo es introducir varios modelos 
arquitectonicos para clases especificas de sistemas de 
aplicaciones software. Cuando haya leido este capitulo: 

• conocera dos organizaciones arquitectonicas fundamentales 
de tos sistemas de negocio, denominados procesamiento por 
lotes y procesamiento transaccional; 

• comprendera la arquitectura abstracta de los sistemas de 
informacion y de gestion de recursos; 

• comprendera como los sistemas dirigidos porcomandos, tales 
como los editores, pueden estructurarse como sistemas de 
procesamiento de eventos; 

• conocera la estructura y organizacion de los sistemas de 
procesamiento de lenguajes. 

Contenidos 

13.1 Sistemas de procesamiento de datos 

13.2 Sistemas de procesamiento de transacciones 

13.3 Sistemas de procesamiento de eventos 

13.4 Sistemas de procesamiento de lenguajes 
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Tal y como se ha explicado en el Capitulo 11, se pueden ver las arquitecturas de los siste- 
mas desde varias perspectivas. Hasta ahora, los analisis de las arquitecturas de sistemas en 
los Capitulos 11 y 12 se han centrado en perspectivas arquitectonicas y cuestiones tales 
como control, distribucion y estructuracion del sistema. En este capitulo, sin embargo, se 
utiliza una aproximacion alternativa y se contemplan las arquitecturas desde la perspectiva 
de una aplicacion. 

Los sistemas de aplicaciones intentan adecuarse a necesidades organizacionales o de ne- 
gocio. Todos los negocios tienen mucho en comun — necesitan contratar a personas, emitir 
facturas, mantener la contabilidad y asi sucesivamente — y esto es especialmente cierto para 
negocios que operan en el mismo sector. Por lo tanto, ademas de las funciones de negocio ge- 
nerales, todas las companias telefonicas necesitan sistemas para conectar las llamadas, ges- 
tionar su red, emitir facturas a los clientes, etcetera. Como consecuencia, las aplicaciones de 
los sistemas que utilizan estos negocios tienen tambien mucho en comun. 

Normalmente, los sistemas del mismo tipo tienen arquitecturas similares, y la diferencia 
entre estos sistemas esta en la funcionalidad detallada que proporcionan. Esto puede ilustrar- 
se por el crecimiento de los sistemas de Planificacion de Recursos de Empresas (ERP) tales 
como el sistema SAP/R3 (Appelrath y Ritter, 2000) y paquetes verticales de software para 
aplicaciones particulares. En estos sistemas, que se tratan brevemente en el Capitulo 18, un 
sistema generico se configura y adapta para crear una aplicacion especifica de negocio. Por 
ejemplo, un sistema para suministrar una gestion de una cadena puede adaptarse para dife- 
rentes tipos de suministradores, articulos y acuerdos contractuales. 

En el analisis que se hace aqui de las arquitecturas de aplicaciones, se presentan modelos 
estructurales genericos de varios tipos de aplicaciones. Se estudia la organizacion basica de 
estos tipos de aplicaciones y, donde resulta apropiado, se descompone la arquitectura de alto 
nivel para mostrar los subsistemas que se incluyen normalmente en las aplicaciones. 

Como disenador de software, usted puede usar arquitecturas de aplicaciones genericas de 
varias formas: 

1. Como un punto departida para el proceso de diseno arquitectonico. S i no esta fami- 
liarizado con este tipo de aplicacion, puede basar sus disenos iniciales sobre arquitec- 
turas genericas. Por supuesto, estas tendran que especializarse para sistemas concre- 
tes, pero son un buen punto de partida para su diseno. 

2. Como una lista de comprobacion de un diseno. Si ha desarrollado un diseno arquitec- 
tonico de un sistema, puede comprobarlo contrastandolo con la arquitectura de apli- 
cacion generica para ver si ha omitido algun componente de diseno importante. 

3 . Como una forma de organizar el trabajo del grupo de desarrollo. La arquitectura de 
la aplicacion identifica caracteristicas estructurales estables de las arquitecturas de los 
sistemas y, en muchos casos, es posible desarrollarlas en paralelo. Usted puede asig- 

nar trabajo a miembros del grupo para implementar diferentes subsistemas dentro de 
la arquitectura. 

4. Como una forma de evaluar los componentes para su reutilizacidn. S i usted tiene 
componentes, podria ser capaz de reutifizarlos; puede comparar estos con las estruc- 
turas genericas para ver si es probable la reutilizacidn en la aplicacion que esta desa- 
rrollando. 

5. Comoun vocabulario para hablar sobre tipos de aplicaciones. Siestatratandouna 
aplicacion especifica o intentando comparar aplicaciones del mismo tipo, entonces 
puede usar los conceptos identificados en la arquitectura generica para hablar de las 
aplicaciones. 
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Hay muchos tipos de sistemas de aplicaciones y, aparentemente, pueden parecermuy dis- 
tintos. Sin embargo, cuando se examina la organizacion arquitectonicade las aplicaciones, 
muchas de estas aplicaciones aparentemente distintas tienen mucho en comun. Ilustramos esto 
describiendo las arquitecturas de cuatro grandes tipos de aplicaciones: 

1. Aplicaciones deprocesamiento de datos. Las aplicaciones de procesamiento de datos 
son aplicaciones conducidas por los datos. Procesan datos por lotes sin intervenciones 
explicitas delusuario durante el procesamiento. Las acciones especificas tomadas por 
la aplicacion dependen de los datos que se estan procesando. Los sistemas de proce- 
samiento por lotes se usan normalmente en aplicaciones de negocio en donde se rea- 
lizan operaciones similares sobre grandes cantidades de datos. Dichas aplicaciones 
manejan un amplio rango de funciones administrativas tales como nominas, factura- 
cion, contabilidad y publicidad. 

1. Aplicaciones de procesamiento de transacciones. Las aplicaciones de procesamiento 
de transacciones son aplicaciones centradas en bases de datos que procesan peticiones 
del usuario para obtener informacion y para actualizar la informacion en una base de 
datos. Estos son los tipos mas comunes de sistemas de negocio interactivos. Se orga- 
nizan de forma que las acciones del usuario no pueden interferir entre si y se manten- 
ga la integridad de la base de datos. Esta clase de sistema incluye sistemas bancarios 
interactivos, sistemas de comercio electronico, sistemas de informacion y sistemas de 
reservas. 

3. Sistemas deprocesamiento de eventos. Esta es una clase muy amplia de aplicaciones 
en las que las acciones del sistema dependen de la interpretacion de eventos en el en- 
torno del sistema. Estos eventos podrian ser la entrada de una orden porun usuario del 
sistema o un cambio en las variables que son monitorizadas por el sistema. Muchas 
aplicaciones basadas en PCs. entre las que se incluyenjuegos, sistemas de edicion ta- 
les como procesadores de texto, hojas de calculo, editores de imagenes y sistemas de 
presentacion son sistemas de procesamiento de eventos. Los sistemas de tiempo real, 
estudiados en el Capitulo 15, tambien se encuentran dentro de esta categoria. 

4. Sistemas deprocesamiento de lenguajes. Los sistemas de procesamiento de lenguajes 
son sistemas en los que las intenciones del usuario se expresan en un lenguaje formal 
(como, por ejemplo, Java). Los sistemas de procesamiento de lenguajes procesan este 
lenguaje en algun formato interno y entonces interpretan su representacion interna. 
Los sistemas deprocesamiento de lenguajes mas conocidos son los compiladores, que 
traducen programas de lenguajes de alto nivel acodigo maquina. Sin embargo, los sis- 
temas de procesamiento de lenguajes se utilizan tambien para interpretar lenguajes de 
comandos para bases de datos, sistemas de informacion y lenguajes de marcado tales 
como XML (Harold y Means, 2002), que se usa de forma amplia para describir ele- 
mentos de datos estructurados. 

Se han elegido estos tipos particulares de sistemas debido a que representan la mayoria de 
sistemas que se usan en la actualidad. Los sistemas de negocio son generalmente sistemas de 
procesamiento de transacciones o de datos, y la mayoria del software de computadoras per- 
sonates se construye sobre una arquitectura de procesamiento de eventos. Los sistemas de 
tiempo real son tambien sistemas de procesamiento de eventos; estas arquitecturas se tratan 
en el Capitulo 15. Todo el desarrollo del software se centra en los sistemas de procesamiento 
de lenguajes tales como compiladores. 

Los sistemas de procesamiento por lotes y procesamiento de transacciones se centran en 
bases de datos. Debido a la importancia fundamental de los datos, estos sistemas son comu- 
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nes para aplicaciones de diferentes tipos que comparten la misma base de datos. Por ejemplo, 
un sistema de procesamiento de datos de negocio que imprime situaciones bancarias usan la 
misma base de datos de clientes al igual que un sistema de procesamiento de transacciones 
que proporciona acceso basado en web para informacion de cuentas. 

Por supuesto, tal y como se vio en el Capitulo 11, las aplicaciones complejas raramente 
siguenun unicomodelo arquitectonico. En su lugar, su arquitectura es la mayoriade las ve- 
ces un hibrido, con diferentes partes de la aplicacion estructuradas de forma diferente. Por lo 
tanto, a) disenar estos sistemas, hay que considerar las arquitecturas de subsistemas indivi- 
duals y tambien como estas tienen que integrarse con la arquitectura del sistema en su tota- 
lidad. 



13.1 Sistemas de procesamiento de datos 

Los negocios necesitan relacionarse con sistemas de procesamiento de datos para soportar 
muchos aspectos de sus negocios tales como el pago de salarios, el calculo y la impresion de 
facturas, el mantenimiento de cuentas y la emision de renovacion para polizas de seguros. 
Como su nombre indica, estos sistemas se centran en datos, y las bases de datos con las que 
se relacionan son normalmente varios ordenes de magnitud mas grandes que los propios sis- 
temas. Los sistemas de procesamiento de datos son sistemas de procesamiento por lotes en 
los que los datos son introducidos y extraidos por lotes a partir de un fichero o base de da- 
tos en lugar de ser introducidos y extraidos por un terminal de usuario. Estos sistemas se- 
leccionan datos para el registro de entradas y, dependiendo del valor de los campos en los 
registros, realizan algunas acciones especificadas en el programa. Pueden volver a escribir 
el resultado del calculo en la base de datos y formatear la entrada y la salida calculada para 
su impresion. 

La arquitectura de los sistemas de procesamiento por lotes tiene tres componentes prin- 
cipales, tal y como se ilustra en la Figura 13.1. Un componente de entrada reune entradas 
desde una o mas fuentes. Un componente de procesamiento realiza calculos utilizando es- 
tas entradas; y un componente de salida genera salidas para ser escritas en la base de datos 
e impresas. Por ejemplo, un sistema de facturas telefonicas toma los datos registrados de 
un cliente y las lecturas realizadas del telefono (entradas) de una centralita telefonica, cal- 
cula los costes para cada cliente (proceso) y entonces imprime facturas (salidas) para cada 
cliente. 
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Los componentes de entrada, procesamiento y salida pueden descomponerse en una es- 
tructurade entrada-proceso-salida. Porejemplo: 

1. Un componente de entrada puede leer algun dato (entrada) desde un fichero o base de 
datos, comprobar la validez de los datos y corregir algunos errores (proceso), y a con- 
tinuacion encolar los datos validos para su procesamiento (salida). 

2. Un componente de procesamiento puede escoger una transaccion de una cola (entra- 
da), realizar algunos calculos sobre los datos y crearun nuevo registro de datos alma- 
cenando los resultados de los calculos (proceso), y a continuacion encolar este nuevo 
registro para su impresion (salida). Algunas veces el procesamiento se realiza dentro 
de la base de datos del sistema y otras veces como un programa separado. 

3. Un componente de salida puede leer registros de una cola (entrada), formatear estos 
de acuerdo con el formato de salida (proceso), y a continuacion enviarlos a una im- 
presora o volver a escribir nuevos registros en la base de datos (salida). 

La naturaleza de los sistemas de procesamiento de datos, en donde los registros o trans- 
acciones se procesan en serie sin necesidad de mantener el estado entre las transacciones, im- 
plica que estos sistemas sean naturalmente orientados a funciones en vez de orientados a ob- 
jetos. Las funciones son componentes que no mantienen informacion del estado interno de 
una invocacion a otra. Los diagramas de flujo de datos, introducidos en el Capitulo 8. son 
una buena manera de describir la arquitectura de los sistemas de procesamiento de datos de 
negocio. 

Los diagramas de flujos de datos constituyen una forma de representar sistemas orien- 
tados a funciones en donde cada rectangulo con bordes redondeados en el flujo de datos re- 
presenta una funcion que implementa algunas transformaciones de datos, y cada flecha re- 
presenta un elemento de datos procesado por la funcion. Los ficheros o almacenes de datos 
se representan como rectangulos. La ventaja de los diagramas de flujo de datos es que mues- 
tran el procesamiento de los datos desde su entrada hasta su salida. Es decir, se pueden ver 
todas las funciones que actuan sobre los datos a medida que se mueven a traves de las eta- 
pas del sistema. La estructura fundamental de un flujo de datos consiste en una funcion de 
entrada que pasa los datos a una funcion de procesamiento y a continuacion a una funcion 
de salida. 

La Figura 13.2 ilustra como pueden utilizarse los diagramas de flujo de datos para mostrar 
una vision mas detallada de la arquitectura de un sistema de procesamiento de datos. Esta fi- 
gura muestra el diseno de un sistema de pago de salarios. En este sistema, la informacion so- 
bre los empleados en la organizacion es leida por el sistema, se calcula el salario mensual y 
las deducciones, y se realizan los pagos. Puede verse como este sistema sigue la estructura ba- 
sica de entrada-proceso-salida: 

1. Las funciones en la parte izquierda del diagrama Lectura de registro deempleado, 
Lectura de datos a pagar mensualmente y Validation de datos de empleado in- 

troducen los datos para cada empleado y comprueban dichos datos. 

2. La funcion Calcula r salario calcula el salario bruto para cada empleado y las deduc- 
ciones a realizar sobre dicho salario. A continuacion se calcula el salario neto men- 
sual. 

3. Las funciones de salida escriben una serie de ficheros que contienen detalles de las de- 
ducciones realizadas y el salario a pagar. Estos ficheros son procesados por otros pro- 
gramas una vez que se han calculado los detalles para todos los empleados. Finalmente 
el sistema imprime una nomina para el empleado que contiene el salario neto y las de- 
ducciones realizadas. 



270 CAPITU LO 13 • Arquitecturas de aplicaciones 



Registros 
empleados 



de"! 
05 I 



c 



Leer registro 
de empleado 



Leer datos de 
pagos mensuales 
— . 



Datos de 
pagos mensuales 1 



Gasto deducible+ 
numero SS+oficina 
tributaria 



Escribir 
transacciones 
» de impuestos j 



Transacciones 
de impuestos 



Registro 
decodificado 
de empieado 






Tasas de | 




pagos mensuales 1 


Registro vSlido 




de empleado ^ 


' 1 j 



Validar datos 
de empleado 



Escribir datos 
^de pensiones 

Pension deducible+ 
niimero SS 



Datos de 
pensiones 



Cakulat 
salario 



Information de pagos 



Datos del \ 
empleado+ 
deducciones 



Imprfmir 
nomina 



1MPRESORA 



Pago neto+informaci6n 
de cuenta bancaria 



Tablas | \ 


\f Escribir \ 


Transacciones I 


de impuestos | 


\ f transacci6n 1 *~ 
\ \^ bancaria M 


del banco J 


Deduction de la 
Seguridad Social+ 
numero SS ^ 




Escribir datos de A 


Datos de la 1 




Seguridad Social^ 


Seguridad Social | 



Figure 13.2 Diagrama de flujo de datos de un sistema de nbminas. 



El modelo arquitectonico de los programas de procesamiento de datos es relativamente 
simple. Sin embargo, en estos sistemas la complejidad de la aplicacion se refleja a menudo 
en los datos que se estan procesando. Por lo tanto, el disefto de la arquitectura del sistema im- 
plica pensar o reflexionar sobre la arquitectura de los dalos (Bracket, 1994) asi como en la 
arquitectura del programa. El diseno de la arquitectura de los datos esta fuera del ambito de 
este libro. 



13.2 Sistemas de procesamiento de transacciones 

Los sistemas de procesamiento de transacciones se disenan para procesar peticiones de usua- 
rio a fin de obtener informacion de una base de datos o peticiones para actualizar la base de 
datos (Lewis eta/., 2003). Tecnicamente, una transaccion de una base de datos es una se- 
cuencia de operaciones tratada como una unica unidad (una unidad atomica). Todas las ope- 
raciones de una transaccion tienen que ser completadas antes de que los cambios en la base 
de datos sean permanentes. Esto significa que los fallos de operaciones dentro de la transac- 
cion no conducen a inconsistencias en la base de datos. 

Un ejemplo de una transaccion es una peticion de un cliente para efectuarun reintegro de 
una cuenta bancaria utilizandoun ATM . Esto implica obtener detalles de la cuenta del cliente, 
comprobar el saldo, modificar el saldo por la cantidad reintegrada y enviar comandos al A T M 
para proporcionar el dinero en efectivo. Hasta que todos estos pasos no hayan sido completa- 
dos, la transaccion esta incompleta y no se modifica la base de datos de cuentas de clientes. 

Desde la perspectiva de un usuario, una transaccion es cualquier secuencia coherente de 
operaciones que satisface un objetivo, tal como «encuentra los horarios de vuelos desde Lon- 
dres a Paris». Si la transaccion del usuario no requiere que la base de datos sea modificada, 
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entonces puede no ser necesario empaquetar estas operaciones como una transaccion tecnica 
de base de datos. 

Los sistemas de procesamiento de transacciones son normalmente sistemas interactivos en 
donde los usuarios realizan peticiones de servicios de forma asincrona. La Figura 13.3 ilus- 
tra la estructura arquitectonicade alto nivelde estas aplicaciones. Primero unusuario realiza 
una peticion al sistema a traves de un componente de procesamiento de E/S. La peticion se 
procesa por alguna logica especifica de la aplicacion. Una transaccion se crea y se envia a un 
gestor de transacciones, el cual normalmente esta embebido en el sistema de gestion de base 
de datos. Despues de que el gestor de transacciones haya asegurado que la transaccion se ha 
realizado correctamente, envia una serial a la aplicacion indicando que el procesamiento ha 
finalizado. 

La estructura entrada-proceso-salida que podemos observar en las aplicaciones de proce- 
samiento de datos tambien se aplican a muchos sistemas de procesamiento de transacciones. 
Algunos de estos sistemas son versiones interactivas de los sistemas de procesamiento por lo- 
res. Por ejemplo, por un lado los bancos dan entrada fuera de linea a todas las transacciones 
de clientes, y despues ejecutan por la noche estas transacciones en un lote utilizando la base 
de datos de cuentas. Esta aproximacion se ha reemplazado en la mayoria de los casos por sis- 
temas interactivos basados en transacciones que actualizan las cuentas en tiempo real. 

Un ejemplo de un sistema de procesamiento de transacciones es un sistema bancario que 
permite a los clientes consultar sus cuentas y extraer dinero de un ATM . El sistema estacom- 
puesto pordos subsistemas software que cooperan: el software del ATM y el software de pro- 
cesamiento de cuentas en el servidor de la base de datos del banco. La entrada y salida de los 
subsistemas se implementa como software en el A T M , mientras que el subsistema de proce- 
samiento esta en el servidor de la base de datos del banco. La Figura 13.4 muestra la arqui- 
tectura de este sistema. Se ha anadido algun detalle al diagrama basico de entrada-proceso- 
salida para mostrar los componentes que pueden estar implicados en las actividades de 
entrada, procesamiento y salida. Deliberadamente, no se ha sugerido como interactuan estos 
componentes internos, ya que la secuencia de operaciones puede diferir de una maquina a otra. 
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En sistemas tales como sistemas de cuentas de clientes bancarios, puede haber diferentes 
formas de inter/actuar con dicho sistema. Muchos clientes interactuaran a traves de ATMs, 
pero el personal del banco utilizara terminales para acceder al sistema. Pueden utilizarse va- 
rios tipos de ATMs y terminales, y algunos clientes y personal pueden acceder a las cuentas 
a traves de navegadores web. 

Para simplificar la gestion de los diferentes protocolos de comunicacion entre terminales, 
los sistemas de procesamiento de transacciones a gran escala pueden incluir middleware que 
comunica todos los tipos de terminales, organiza y serializa los datos desde los terminales, y 
envia los datos para su procesamiento. Este middleware, que analiza brevemente en el Capi- 
tulo 12, puede ser llamado por un monitor de teleprocesamiento o un sistema de gestion de 
transacciones. El sistema CICS de IBM (Horswill y Miller, 2000) es un ejemplo de dicho sis- 
tema muy extensamente usado. 

La Figura 13.5 muestra otra vision de la arquitectura de un sistema de cuentas bancarias 
que maneja transacciones de cuentas personales desde los ATMs y terminales en un banco. 
El monitor de teleprocesamiento maneja la entrada y serializa las transacciones, que convier- 
te en consultas a la base de datos. El procesamiento de las consultas tiene lugar en el sistema 
de gestion de base de datos. Los resultados se envian de vuelta al monitor de teleprocesa- 
miento, el cual registra los terminales que han realizado la peticion. A continuacion este sis- 
tema organiza los datos en un formulario que puede ser manejado por el software del termi- 
nal y le devuelve los resultados de la transaccion. 

13.2.1 Sistemas de Informaclon y de gestion de recursos 

Todos los sistemas que implican una interaccion con una base de datos compartida pueden 
considerarse como sistemas de informacion basados en transacciones. Un sistema de infor- 
macion permite el acceso controlado a una gran base de informacion, como un catalogo de 
biblioteca, un horario de vuelos o los registros de pacientes en un hospital. El desarrollo de 
la WWW significa que un enorme numero de sistemas de informacion pasaron de ser siste- 
mas organizacionales especializados a ser sistemas de proposito general universalmente ac- 
cesibles. 

La Figura 13.6 es un modelo muy general de un sistema de informacion. El sistema se mo- 
dela utilizando una aproximacion de maquina abstracta o por capas (vista en la Sec- 
cion 1 1 .2.3), en donde la capa superior soporta la interfaz de usuario y la capa inferior la base 
de datos del sistema. La capa de comunicaciones con el usuario maneja todas las entradas y 
salidas de la interfaz de usuario, y la capa de recuperacion de informacion incluye logica es- 
pecifica de la aplicacion para acceder y actualizar la base de datos. Tal y como veremos mas 
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adelante, las capas en este modelo pueden hacerse corresponder de forma directa con servi- 
dores en un sistema basado en Internet. 

Como ejemplo de una instanciacion de este modelo por capas, la Figura 13.7 presenta la 
arquitectura del sistema LIBS YS. Recuerde que este sistema permite a los usuarios accedera 
documentos en bibliotecas remotas y descargarlos para su impresion. Se ha afiadido detalle a 
cada capa en el modelo identificando los componentes que soportan comunicaciones con el 
usuario y el acceso y recuperacion de informacion. Deberla notarse tambien que la base de 
datos es una base de datos distribuida. Los usuarios realmente se conectan, a traves del siste- 
ma, con las bases de datos de las bibliotecas que proporcionan los documentos. 

La capa de comunicacion con el usuario en la Figura 13.7 incluye tres componentes prin- 
cipales: 

1. El cotnponente de identification de usuario (login) UBSYS identifica y autentica a los 
usuarios. Todos los sistemas de informacion que restringen el acceso a un conjunto co- 
nocido de usuarios necesitan tener autenticacion de usuario como una parte funda- 
mental de sus sistemas de comunicacion con el usuario. La autenticacion de usuario 
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puede serpersonal, pero en sistemas de comercio electronico, puede tambien requerir 
que se proporcionen detalles sobre la tarjeta de credito. 

2. El componente degestidn de consultasy formularios gestiona los formularios que pue- 
den presentarse al usuario y proporciona facilidades de consulta permitiendo al usua- 
rio solicitar informacion del sistema. De nuevo, los sistemas de informacion deben in- 
cluir un componente que proporcione estas facilidades. 

3. El componente degestidn de impresidn es especifico de LIBSYS. Controla la impre- 
sion de documentos que, porrazones de derechos de autor, puede estar restringida. Por 
ejemplo, algunos documentos solamente pueden imprimirse una vez en impresoras de 
labibliotecaregistrada. 

La capa de modificacion y recuperacion de informacion en el sistema LIBSYS incluye 
componentes especificos de la aplicacion que implementan la funcionalidad del sistema. Es- 
tos componentes son: 

1 . Busqueda distribuida. Este componente busca documentos como respuesta a consul- 
tas del usuario a traves de todas las bibliotecas que estan registradas en el sistema. La 
lista de bibliotecas conocidas se mantiene en el indice de bibliotecas. 

2. Recuperacion de documentos. Este componente recupera el documento o documentos 
que son solicitados por el usuario al servidor en el que se esta ejecutando el sistema 
LIBSYS. 

3. Gestor de derechos. Este componente maneja todos los aspectos de la gestion de de- 
rechos digitales y derechos de autor. Almacena un seguimiento de quien ha solicitado 
los documentos y, por ejemplo, asegura que no puedan realizarse multiples peticiones 
para el mismo documento por la misma persona. 

4. Registro de cuentas. Este componente registra todas las solicitudes y, si es necesario, 
maneja cualquier cargo que sea realizado por las bibliotecas en el sistema. Tambien 
produce informes de gestion sobre el uso del sistema. 

Nosotros podemos observar la misma estructura generica de cuatro capas en otro tipo de 
sistema de informacion, como por ejemplo los sistemas disefiados para soportar la asignacion 
de recursos. Los sistemas de asignacion de recursos gestionan una cantidad fija de algun re- 
curso determinado, como entradas para un concierto o un partido de futbol. Estos son asig- 
nados a los usuarios que solicitan dicho recurso al suministrador. Los sistemas de venta de en- 
tradas son un ejemplo obvio de un sistema de asignacion de recursos, pero un gran numero 
de programas aparentemente distintos son tambien realmente sistemas de asignacion de re- 
cursos. Algunos ejemplos de este tipo de sistemas son: 

1. Sistemas de horarios que asignan aulas a franjas horarias. El recurso a asignar aqui es 
un periodo de tiempo, y normalmente hay un gran numero de restricciones con cada 
demanda del recurso. 

2. Sistemas de biblioteca que gestionan el prestamo y retirada de libros u otros ele- 
mentos. En este caso los recursos que se estan asignando son los elementos que pue- 
den ser prestados. En este tipo de sistemas, los recursos no son simplemente asigna- 
dos, sino que algunas veces deben eliminarse las asignaciones hechas al usuario del 
recurso. 

3. Sistemas de gestion de traflco aereo en donde el recurso que se esta asignando es un 
sector del espacio aereo para que se mantenga la separacion entre los aviones que es- 
tan siendo gestionados por el sistema. De nuevo, este implicauna asignacion dinamica 
y reasignacion del recurso, ya que el recurso es virtual en vez de un recurso fisico. 
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Los sistemas de asignacion de recursos son una clase de aplicaciones ampliamente utili- 
zada. Si echamos un vistazo a su arquitectura con detalle, podemos ver como esta se aseme- 
ja al modelo de sistema de informacion de la Figura 13.6. Los componentes de un sistema de 
asignacion de recursos (mostrado en la Figura 13.8) comprenden: 

1. Una base de datos de recursos que almacena detalles de los recursos que se estan asig- 
nando. Los recursos pueden ser anadidos o eliminados de esta base de datos. Por ejem- 
plo, en un sistema de biblioteca, la base de datos de recursos incluye detalles de todos 
los elementos que pueden ser prestados a los usuarios de la biblioteca. Normalmente 
esto se implementa utilizando un sistema de gestion de base de datos que incluye un 
sistema de procesamiento de transacciones. El sistema de gestion de base de datos tam- 
bien incluye facilidades para el bloqueo de recursos de forma que el mismo recurso no 
pueda ser asignado a usuarios que realizan solicitudes simultaneamente. 

2. Un conjunto de regias que describe las reglas para la asignacion de recursos. Por 
ejemplo, un sistema de biblioteca normalmente limita a quien puede asignarse el re- 
curso (usuarios registrados por la biblioteca), el periodo de tiempo que un libro u otro 
articulo puede serprestado, el maximo numero de libros que pueden prestarse, y asi 
sucesivamente. Todo esto se encapsula en el componente de control de permisos de re- 
cursos. 

3 . Un componente de gestion de recursos que permite al suministrador de los recursos 
afiadir, editar o borrar recursos del sistema. 

4. Un componente de asignacion de recursos que actualiza la base de datos de recursos 
cuando los recursos son asignados y asocia estos recursos con detalles del solicitante 
del recurso. 

5. Un modulo de autenticacion de usuarios que permite al sistema comprobar que re- 
cursos estan siendo asignados a un usuario acreditado. En un sistema de biblioteca, 
este podria ser una tarjeta de biblioteca legible por una maquina; en un sistema de asig- 
nacion de entradas, podria ser una tarjeta de credito que verifica que el usuario es ca- 
paz de pagar el recurso. 

6. Un modulo de gestion de consultas que permite a los usuarios consultar que recursos es- 
tan disponibles. En un sistema de biblioteca, esto podria basarse normalmente en con- 
sultas de elementos concretos; en un sistema de venta de entradas, podria implicar una 
visualizacion grafica mostrando que entradas estan disponibles para fechas concretas. 
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7. Un componente de entrega de recursos que prepara los recursos para su entrega al so- 
licitante. En un sistema de venta de entradas, esto podria implicar preparar un correo 
el ectronico de confirmacion y enviar una peticion a una impresora de billetes para im- 
primir los billetes y los detalles de donde deberian serenviados. 

8. Un componente de interfaz de usuario (a menudo un navegador web) que esta fuera 
del sistema y permite al solicitante del recurso realizar consultas y peticiones para el 
recurso que se va a asignar. 

Esta arquitectura por capas puede llevarse a cabo de varias formas. El software de siste- 
mas de informacion puede organizarse para que cada capa sea un componente a gran escala 
que se ejecuta sobre un servidor distinto. Cada capa define sus interfaces externas y toda la 
comunicacion tiene lugar a traves de estas interfaces. De forma alternativa, si el sistema de 
informacion completo se ejecuta sobre una unica computadora, entonces las capas interme- 
dias se implementan normalmente como un unico programa que se comunica con la base de 
datos a traves de sus APIs. Una tercera alternativa consiste en implementar componentes de 
grano fino como distintos servicios web (discutidos en el Capitulo 12) y componer estos de 
forma dinamicade acuerdo con las peticiones del usuario. 

Las implementaciones de los sistemas de informacion y de gestion de recursos basadas en 
los protocolos de Internet son actualmente la forma mas habitual. La interfaz de usuario en 
estos sistemas se implementa usando un navegador web. La organizacion de los servidores en 
estos sistemas refleja el modelo generico de cuatro capas presentado en la Figura 13.6. Estos 
sistemas se implementan normalmente como arquitecturas cliente-servidor multicapa, tal y 
como se indico en el Capitulo 12. La organizacion del sistema se muestra en la Figura 13.9. 
El servidor web es responsable de todas las comunicaciones con el usuario; el servidor de apli- 
caciones es responsable de implementar la logicaespecificade la aplicacion, asicomo las pe- 
ticiones de almacenamiento y recuperacion de informacion; el servidor de base de datos mue- 
ve la informacion a y desde la base de datos. El uso de multiples servidores permite un 
elevado rendimiento y hace posible manejar cientos de transacciones por minuto. 

Los sistemas de comercio electronico son sistemas de gestion de recursos basados en In- 
ternet que son diseflados paraaceptarpeticioneselectronicasde articulos o servicios y a con- 
tinuacion organizar la entrega de estos productos o servicios al cliente. Hay un amplio rango 
de estos sistemas actualmente en uso que van desde sistemas que permiten servicios tales 
como laconcertacion del alquilerde vehiculos hasta sistemas que soportan la peticion de ar- 
ticulos tangibles tales como libros o comestibles. En un sistema de comercio electronico, la 
capa especifica de la aplicacion incluye funcionalidad adicional para soportar una «venta a la 
carta» en la que los usuarios pueden incluir varios elementos en distintas transacciones, y a 
continuacionpagarpor ellos conjuntamente en una unica transaccion. 



13.3 Sistemas de procesamiento de eventos 

Los sistemas de procesamiento de eventos responden a eventos en el entorno del sistema o in- 
terfaz del usuario. Tal y como vimos en el Capitulo 11, la principal caracteristica de los sis- 
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temas de procesamiento de eventos es que la llegada de los eventos es impredecible y el sis- 
tema debe ser capaz de tratar estos eventos cuando ocurran. 

Todos nosotros usamos sistemas basados en eventos como estos en nuestras propias com- 
putadoras — procesadores de texto, sistemas de presentaciones y juegos estan lodos conduci- 
dos por eventos desde la interfaz de usuario — . El sistema detecta e interpreta los eventos. Los 
eventos de interfaz de usuario representan comandos implicitos al sistema, que realiza algu- 
na accion como respuesta a ese comando. Por ejemplo, si usted esta utilizando unprocesador 
de texto y pulsa dos veces el raton sobre unapalabra, el evento de doble pulsacion significa 
«selecciona esa palabra». 

Los sistemas de tiempo real, los cuales realizan acciones en «tiempo real» como respues- 
ta a algunos estimulos externos, son tambien sistemas de procesamiento basados en eventos, 
Sin embargo, para sistemas de tiempo real, los eventos no son normalmente eventos de inter- 
faz de usuario, sino eventos asociados con servidores o actuadores en el sistema. Debido a la 
necesidad de respuesta en tiempo real a eventos no predecibles, estos sistemas de tiempo real 
se organizan normalmente como un conjunto de procesos cooperativos. En el Capitulo 15 se 
tratan las arquitecturas genericas para sistemas de tiempo real. 

En esta seccion, nos centramos en la descripcion de la arquitectura generica de los siste- 
mas de edicion. Los sistemas de edicion son programas que se ejecutan sobre PCs o estacio- 
nes de trabajo y que permiten a jos usuarios editar documentos tales como documentos de tex- 
to, diagramas o imagenes. Algunos editores se centran en la edicion de un unico tipo de 
documento, tales como imagenes de una camara digital o escaner. Otros, entre ellos la mayo- 
ria de procesadores de texto, son multieditores e incluyen soporte para editar diferentes tipos 
de documentos que incluyen texto y diagramas, incluso se puede pensar en una hoja de cal- 
culo como un sistema de edicion en el que se editan las celdas de la hoja. Por supuesto, las 
hojas de calculo tienen funcionalidades adicionales para llevar acabo los calculos. 

Los sistemas de edicion tienen varias caracteristicas que los distinguen de otros tipos sis- 
temas y que influyen en su diseno arquitectonico: 

1 . Los sistemas de edicion son principalmente sistemas para un unico usuario. Por lo tan- 
to, no tienen que tratar los problemas de multiples accesos concurrentes a los datos y 
tienen una gestion de los datos mas sencilla que los sistemas basados en transaccio- 
nes. Incluso aunque los datos sean compartidos, la gestion de transacciones no se usa 
normalmente debido a que las transacciones consumen mucho tiempo y se utilizan me- 
todos alternativos para mantener la integridad de los datos. 

2. Tienen que proporcionar una rapida realimentacion de las acciones del usuario tales 
como «seleccionar» y «borrar». Esto significa que tienen que funcionar con represen- 
taciones de los datos que se almacenan en la memoria de la computadora en vez de en 
el disco. Debido a que los datos estan en la memoria volatil, pueden perderse si hay 
un fallo en el sistema; por lo tanto, los sistemas de edicion deberianrealizaralguna pre- 
vision para la recuperacion de errores. 

3. Las sesiones de edicion son normalmente mucho mas largas que las sesiones que im- 
plican peticiones de articulos, o larealizacion de algunaotra transaccion. De nuevo, 
esto significa que hay un gran riesgo de perdida si ocurren problemas. Por lo tanto, mu- 
chos sistemas de edicion incluyen facilidades de recuperacion que automaticamente 
guardan el trabajo en curso y recuperan el trabajo para el usuario en el caso de que se 
produzca un fallo en el sistema. 

Una arquitectura generica para un sistema de edicion se muestra en la Figura 13.10 como 
un conjunto de objetos que interactuan. Los objetos en el sistema son activos en vez de pasi- 
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vos (vease el Capitulo 14) y pueden operar concurrentemente y de forma autonoma. Basica- 
mente, los eventos de la pantalla son procesados e interpretados como comandos. Esto ac- 
tualiza una estructura de datos, que se vuelve a visualizar a continuacion sobre la pantalla. 
Las responsabilidades de los componentes arquitectonicos mostrados en laFigura 13.10 

son: 

1. Pantalla. Este objeto monitoriza el segmento de memoria de la pantalla y detecta la 
ocurrencia de eventos. A continuacion, estos eventos se envian al objeto de procesa- 
miento de eventos junto con sus coordenadas de pantalla. 

2. Evento. Este objeto es disparadoporunevento originado desde la Pantalla. Utiliza el 
conocimiento sobre lo que se esta visualizando para interpretar este evento y traducirlo 
al comando de edicion adecuado. A continuacion, este comando se envia al objeto res- 
ponsable de la interpretacion de comandos. Para los eventos mas frecuentes, tales 
como pulsaciones de raton o pulsaciones de teclas, el objeto evento puede comunicarse 
directamente con la estructura de datos. Esto permite actualizaciones mas rapidas de 
dicha estructura. 

3 . 0 rd e n . Este objeto procesa un comando que proviene del objeto evento y realiza una 
llamada al metodo adecuado en el objeto Editor de datos para ejecutar el comando. 

4. Editor de datos. Cuando se llama al comando adecuado en el objeto Editor de datos, 
se actualiza la estructura de datos y se llama al metodo Actualizar en Visualization 

para visualizar los datos modificados. 
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5. Datos auxiliares. Ademas de la propia estructura de datos, los editores gestionan otros 
datos tales como estilos y preferencias. En este modelo arquitectonico sencillo, hemos 
reunido a todos ellos bajo el nombre de Datos auxiliares. Algunos comandos del edi- 
tor, tales como un comando para iniciaruna revision ortografica, son implementados 
por un metodo de este objeto. 

6. Sistema de f icheros. Este objeto maneja todas las operaciones para abrir y guardar fi- 
cheros. Estos pueden ser ficheros de datos auxiliares o ficheros del editor de datos. 
Para evitar la perdida de datos, muchos editores tienen facilidades de autograbacion 
para guardar la estructura de los datos de forma automatica. Esta puede entonces ser 
recuperada en caso de ocurrencia del evento de fallo del sistema. 

7. Visualizacion. Este objeto mantiene un seguimiento de laorganizacionde loquesevi- 
sualiza en la pantalla. Realiza una llamada al metodo Refrescar del objeto Pantalla 
cuando el contenido de la pantalla ha sido modificado. 

Debido a la necesidad de una rapida respuesta a los comandos del usuario, los sistemas de edi- 
cion no tienen un controlador central que realiza llamadas a los componentes para llevar a cabo 
una accion. En su lugar, los componentes criticos en el sistema se ejecutan concurrentemente y pue- 
den comunicarse directamente (por ejemplo, el procesador de eventos puede comunicarse direc- 
tamente con el editor de la estructura de datos) para que pueda lograrse un mayor rendimiento. 



13.4 Sistemas de procesamiento de lenguajes 

Los sistemas de procesamiento de lenguajes aceptan lenguaje natural o artificial como entra- 
da y generan alguna otra representacion de ese lenguaje como salida. En ingenieria del soft- 
ware, los sistemas de procesamiento de lenguajes mas extensamente usados son los compila- 
dores, que traducen un lenguaje de programacion artificial de alto nivel a codigo maquina, 
pero otros sistemas de procesamiento de lenguajes traducen una descripcion de datos en X M L 
a comandos de consulta de una base de datos y sistemas de procesamiento de lenguaje natu- 
ral que intentan traducir un lenguaje natural a otro. 

En la Figura 13.11 se ilustra la arquitectura de un sistema de procesamiento de lenguajes 
en su nivel mas abstracto. Las instrucciones describen lo que liene que realizarse y tienen que 
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traducirse por un traductor a algun formato interno. Las instrucciones se corresponden con las 
instrucciones maquina para una maquina abstracta. A continuacion, estas instrucciones son 
interpretadas por otro componente que obtiene las instrucciones para su ejecucion y las eje- 
cuta usando, si es necesario, datos del entorno. La salida del proceso es el resultado de inter- 
pretar las instrucciones sobre los datos de entrada. Por supuesto, para muchos compiladores 
el interprete es una unidad hardware que procesa instrucciones maquina y la maquina abs- 
tracta es un procesador real. Sin embargo, para lenguajes como Java, el interprete es un com- 
ponente software. 

Los sistemas de procesamiento de lenguajes se usan en situaciones en las que la forma mas 
facil de resolverunproblema es especificar esa solucioncomo un algoritmo o como una des- 
cripcion de los datos del sistema. Por ejemplo, las herramientas meta-CASE son generadores 
de programas que se utilizan para crear herramientas CASE especificas para soportar meto- 
dos de ingenieria del software. Las herramientas meta-CASE incluyen una descripcion de los 
componentes del metodo, sus reglas y asi sucesivamente, escritas en un lenguaje de proposi- 
to especifico que es analizada sintactica y semanticamente para configurar la herramienta 
CASE generada. 

Los traductores en un sistema de procesamiento de lenguajes tienen una arquitectura ge- 
nerica (Figura 13.12) que incluye los siguientes componentes: 

1 . Un analizador lexico, que toma como entrada los simbolos del lenguaje y los convierte 
a un formato interno. 

2. Una tabla de simbolos, que almacena informacion sobre los nombres de las entidades 
(variables, nombres de clases, nombres de objetos, etc.) usadas en el texto que se esta 
traduciendo. 

3. Un analizador sintactico, que comprueba la sintaxis del lenguaje que se esta tradu- 
ciendo. Utiliza una gramatica definida del lenguaje y construye un arbol sintactico. 

4. Un arbol sintactico, que es una estructura interna que representa al programa que se 
esta compilando. 

5. Un analizador semantico, que utiliza informacion del arbol sintactico y de ta tabla de 
simbolos para comprobar la correccion semantica del texto en el lenguaje de entrada. 

6. Un generador de codigo, que «recorre» el arbol sintactico y genera codigo de maqui- 
na abstracta. 

Tambien podrian incluirse otros componentes que transforman el arbol sintactico para me- 
jorar la eficiencia y eliminar redundancias del codigo maquina generado. En otros tipos de sis- 
temas de procesamiento de lenguajes, tales como un traductor de lenguaje natural, el codigo 
generado es realmente el texto de entrada traducido a otro lenguaje. 

Los componentes que forman un sistema de procesamiento de lenguajes pueden organi- 
zarse de acuerdo con diferentes modelos arquitectonicos. Como apuntan Garlan y Shaw (Gar- 
Ian y Shaw, 1993), los compiladores pueden implementarse utilizando un modelo compues- 
to. Puede utilizarse una arquitectura de flujo de datos con la tabla de simbolos actuando como 
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un repositorio para datos compartidos. Las fases de analisis lexico, sintactico y semantico se 
organizan de forma secuencial, como se muestra en la Figura 13.12. 

Este modelo de compilacion de flujo de datos todavia se usa en general. Es efectivo en en- 
tornos de procesamiento por lotes en donde los programas son compilados y ejecutados sin 
la interaccion del usuario. Es menos efectivo cuando el compilador tiene que ser integrado con 
otras herramientas de procesamiento de lenguajes tales como sistemas de edicion estructura- 
dos, undepurador interactivo o un programa de impresion. Acontinuacion, los componentes 
genericos del sistema pueden organizarse en un modelo basado en repositorio, como se mues- 
tra en la Figura 13.13. 

Esta figura muestra como un sistema de procesamiento de lenguajes puede formar parte de 
un conjunto integrado de herramientas de soporte de programacion. En este ejemplo, la tabla 
de simbolos y el arbol sintactico actiian como un repositorio central de informacion. Las he- 
rramientas o fragmentos de herramientas se comunican a traves de el. Otra informacion que 
a menudo esta embebida en las herramientas, como la definicion de la gramatica y la defini- 
cion del formato de salida del programa, ha sido eliminada de las herramientas y se ha incluido 
en el repositorio. Por lo tanto, un editor dirigido por la sintaxis puede comprobar que la sin- 
taxis de un programa es correcta al mismo tiempo que esta siendo escrito, y una impresora 
puede generar listados del programa en un formato que es facil de leer. 
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PUNTOS CLAVE 

• Los modelos genericos de las arquitecturas de sistemas de aplicaciones nos ayudan a entender el funciona- 
miento de las aplicaciones, comparar aplicaciones del mismo tipo, validar Eos disenos de los sistemas de apli- 
caciones y evaluar componentes a gran escala para su reutilizacion. 

• Muchas aplicaciones pertenecen a una de las cuatro clases de aplicaciones genericas o son combinaciones 
de estas aplicaciones genericas. Los cuatro tipos de aplicaciones genericas explicadas a qui son sistemas de 
procesamiento de datos, sistemas de procesamiento de transacciones, sistemas de procesamiento de even- 
tos y sistemas de procesamiento de lenguajes. 
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□ tema de las arquitecturas de aplicaciones se ha descuidado durante mucho tiempo; los autores de libros y artf- 
culos sobre arquitecturas de software tienden a centrarse en principios abstractos o en arquitecturas de Imeas de 
productos. 

Databases and Transaction Processing: An Application-oriented Approach. Este no es un libra sobre arquitecturas 
software, pero describe los principios de las aplicaciones de procesamiento de transacciones y centradas en los da- 
tes. (P. M. Lewis ef a/., 2003, Ad di son-Wesley.) 

Design and Use of Software Architectures. Este libra adopta una aproximacion de Imeas de productos para las ar- 
quitecturas software y, por lo tanto, estudia (a arquitectura desde la perspectiva de una aplicacion. 0- Bosch, 2000, 
Addison-Wesley.) 
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13.1 Explique como pueden utilizarse las arquitecturas de las aplicaciones genericas aqui descritas para ayu- 
dara! disenador a tomar decisiones sobre la reutilizacion del software. 

132 Usando los cuatro tipos de aplicaciones basicos introducidos en este capitulo, clasifique los siguientes sis- 
temas y explique su clasif icacion: 

• Un sistema de punto de venta en un supermercado. 

• Un sistema que envfa recordatorios de que deben pagarse las suscripciones a revistas. 

• Un sistema de album de fotos que proporciona algunas facilidades para restaurar fotografias antiguas. 
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• Un sistema que lee paginas web para usuarios invidentes. 

• Un juego interactivo en el que los personajes se mueven por la pantalla, superan obstaculos y encuen- 
tran tesoros. 

• Un sistema de control de inventario que mantiene un seguimiento de que articulos se encuentran en al- 
macen y automaticamente genera ordenes para nuevos pedidos cuando el nivel de almacenamiento 
esta pordebajo de un cierto valor. 

133 Basandose en un modelo de entrada-proceso-salida, amplie la funcion Calcular salario de la Figura 13.2 y 
dibuje un diagrama de flujo de datos que muestre los calculos llevados a cabo en dicha funcion. Necesita 
la siguiente informacion para realizaresto: 

• El registro del empleado identifica la categoria de un empleado. A continuacion, esta categoria seusa 
para buscar en la tabla de salarios. 

• A los empleados por debajo de una determinada categoria se les puede pagar las horas extras al mis- 
mo precio que las horas de trabajo normales. Las horas extras que se les deben pagar se indican en su 
registro de empleado. 

• La cantidad de impuestos deducidos depende del codigo de impuestos del empleado (indicado en el 
registro) y de su salario anual. Las deducciones mensuales para cada codigo y salario estandar se in- 
dican en las tablas de impuestos. Estas son ampliadas o reducidas proporcionalmente dependiendo de 
las relaciones entre el salario actual y el salario estandar utilizado. 

134 Explique por que la gestion de transacciones en sistemas en los que las entradas del usuario pueden pro- 
vocar cambios en la base de datos. 

135 Utilizando el modelo basico de un sistema de informacion como el presentado en la Figura 13.6, muestre 
los componentes de un sistema de informacion que permita a los usuarios ver la informacion sobre los vue- 
los de llegada y de salida de un determinado aeropuerto. 

13.6 Utilizando la arquitectura por capas de la Figura 13.8, muestre los componentes de un sistema de gestion 
de recursos que podria utilizarse para gestionar la reservas de habitaciones de un hotel. 

13.7 En un sistema de edicion, todos los eventos de la interfaz de usuario pueden ser traducidos en comandos 
implicitos o explicitos. Explique por que, en la Figura 13.10, el objeto Evento se comunica directamente con 
la estructura de datos del editor asi como con el objeto Comando. 

13.8 Modifique la Figura 13.10 para mostrar la arquitectura generica de un sistema de hoja de calculo. Base su 
diseno en las caracteristicas de cualquier sistema de hoja de calculo que usted haya usado. 

13.9 iCual es la funcion del componente arbol sintactico en un sistema de procesamiento de lenguajes? 

13.10 Usando el modelo generico de un sistema de procesamiento de lenguajes aqui presentado, disene la ar- 
quitectura de un sistema que acepte comandos en lenguaje natural y los traduzca en consultas a una base 
de datos en un lenguaje como SQL. 



14 



Diseno orientado 
a objetos 



Objetivos 

El objetivo de este capitulo es introducir un enfoque de diseno 
de software en el que el diseno se representa como objetos que 
interactuan. Cuando termine de leer este capitulo : 

• conocera como se representa un diseno de software como un 
conjunto de objetos que interactuan entre si y que 
administran su propio estado y operaciones; 

• conocera las actividades mas importantes en un proceso 
general de diseno orientado a objetos; 

• comprendera los diversos modelos que se utilizan para 
documentar diseno orientado a objetos; 

• habra sido introducido en la representacion de estos modelos 
en el Lenguaje Unificado de Modelado (UML). 

Contenidos 

14.1 Objetos y clases 

14.2 Un proceso de diseno orientado a objetos 

14.3 Evolucion del diseno 
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Un sistema orientado a objetos esta compuesto de objetos que interactuan, los cuales mantie- 
nen ellos mismos su estado local y proveen operaciones sobre su estado (Figura 14.1). La re- 
presentacion del estado es privada y no se puede acceder a ella directamente desde fuera del 
objeto. El proceso de diseno orientado a objetos comprende el diseno de clases de objetos y 
las relaciones entre estas clases. Las clases definen los objetos del sistema y sus interaccio- 
nes. Cuando el diseno se implementa como un programa ejecutable, los objetos requeridos se 
crean dinamicamente utilizando las definiciones de las clases. 

El diseno orientado a objetos es parte del desarrollo orientado a objetos en el que se utili- 
za una estrategia orientada a objetos en el proceso de desarrollo: 

• El andlisis orientado a objetos comprende el desarrollo de un modelo orientado a obje- 
tos del dominio de aplicacion. Los objetos identificados reflejan las entidades y opera- 
ciones que se asocian con el problema a resolver. 

• El diseno orientado a objetos comprende el desarrollo de un modelo orientado a ob- 
jetos de un sistema software para implementar los requerimientos identificados. Los 
objetos en un diseno orientado a objetos estan relacionados con la solucion del pro- 
blema por resolver. Pueden existir relaciones estrechas entre algunos objetos del 
problema y algunos objetos de la solucion, pero inevitablemente el disenador tiene que 
agregar nuevos objetos para transformar los objetos del problema e implementar la 
solucion. 

• La programacion orientada a objetos se refiere a implementar el diseno de software uti- 
lizando un lenguaje de programacion orientado a objetos, como Java. Un lenguaje orien- 
tado a objetos provee los recursos para definir las clases y un sistema para crear los ob- 
jetos correspondientes a las clases. 

La transicion entre estas etapas de desarrollo se lleva a cabo, idealmente, sin problemas, 
utilizando notaciones compatibles entre las etapas. Pasar a la siguiente etapa implica refinar 
la etapa previa agregando algun detalle a las clases existentes y crear nuevas clases con el fin 
de proveer nuevas funcionalidades. Puesto que la informacion se oculta dentro de los obje- 
tos, las decisiones del diseno detallado de la representacion de los datos se puede retrasar 
hasta que el sistema se implemente. En algunos casos, las decisiones sobre la distribucion 
de los objetos y si estos se implementan de forma secuencial o concurrente tambien se pue- 
den retrasar. 

Esto significa que los disefiadores de software no estan condicionados por los detalles de 
la implementacion del sistema. Pueden formular disefios que se adapten a los diversos entor- 
nos de ejecucion. Esto es ejemplificado en el enfoque de Arquitectura Dirigida por el Mode- 
lo (MDA), el cual propone que el sistema debe serdisenado explicitamente en dos niveles 
(Kleppe etal., 2003), un nivel independiente de la implementacion y otro dependiente de esta. 
Se diseflaun modelo abstracto del sistema en el nivel independiente de la implementacion, y 
este es dirigido hacia un modelo mas detallado dependiente de la plataforma, el cual puede 
utilizarse como base para lageneracionde codigo. Actualmente, laaproximacion MD A es to- 
davia experimental y no esta claro su nivel de adopcion. 

Los sistemas orientados a objetos son mas faciles de mantener que los sistemas desarro- 
llados con otras aproximaciones, debido a que los objetos son independientes. Tales sistemas 
pueden ser entendidos y modificados como entidades independientes. Cambiar la implemen- 
tacion de un objeto o agregarle servicios no debe afectar a los otros objetos del sistema. Pues- 
to que los objetos estan asociados a cosas, a menudo existe una correspondencia clara entre 
las entidades del mundo real (como los componentes de hardware) y los objetos de control 
del sistema. Esto mejora lacomprensiony, por lo tanto, lamantenibilidad del diseno. 
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Los objetos son componentes potencialmente reutilizables debido a que son encapsula- 
mienlos independientes del estado y las operaciones. Los diseflos se pueden desarrollarutili- 
zando objetos creados en los diseflos previos. Esto reduce los costes de diseflo, programacion 
y validacion. Tambien conduce a la utilizacion de objetos estandar (por lo que se mejora la 
comprension del diseflo) y reduce los riesgos implicados en el desarrollo de software. Sin em- 
bargo, como se explica en los Capitulos 18 y 19, algunas veces la reutilizacion se implemen- 
ta de una mejor forma si se utilizan colecciones de objetos (componentes o marcos de traba- 
jo) en lugarde objetos individuales. 

Se han propuesto diversos metodos de diseflo orientado a objetos (Coad y Yourdon, 1990; 
Robinson, 1992; Jacobson era/., 1993; Graham, 1994; Booch, 1994). Se ha definido una uni- 
ficacion de las notaciones utilizadas en estos metodos (UML). El Proceso Unificado de Ra- 
cional (RUP), que se analizo en el Capitulo 4. ha sido disenado para explotar los modelos que 
pueden expresarse en U M L (Rumbaugh etal. 1999). La notacion U M L se utilizara a lo lar- 
go de este capitulo. 

En el Capitulo 17 se expondraun sistema desarrollado basado en un diseflo amplio que 
puede ser criticado debido al extenso esfuerzo de analisis y diseflo no ajustado al desarrollo 
y entrega incremental. Para atajar este problema, se han desarrollado los llamados metodos 
agiles, los cuales reducen o eliminan completamente la actividad de diseflo orientado a obje- 
tos. Nuestro punto de vista respecto a este tema es amplio, el diseflo «pesado» no es necesa- 
rio en sistemas de negocios de tamaflo pequeflo o mediano. Sin embargo, para sistemas gran- 
des, particularmente en sistemas criticos, es esencial asegurar que los equipos trabajen en 
diferentes partes del sistema adecuadamente coordinados. Poresta razon, no se han usado los 
ejemplos previos de la biblioteca o del sistema de inyeccion de insulina en este capitulo. En 
su lugar, se ha utilizado un ejemplo que es parte de un sistema mucho mayor donde el enfo- 
que del diseflo orientado a objetos es mas util. 

Esta vision es reflejada, y en algunos casos extendida, en el Proceso Unificado de Racio- 
nal que orienta el desarrollo iterativo y entregas incrementales de grandes sistemas software. 
Este proceso es un proceso de desarrollo iterativo basado alrededor de casos de uso para ex- 
presar los requerimientos y el diseflo orientado a objetos, centrandose particularmente en el 
diseflo de la arquitectura. 

El proceso de diseflo que se describe en la Seccion 14.2 tiene algunas cosas en comun con 
el RUP. pero con menos enfasis en el desarrollo dirigido por casos de uso. La utilizacion de 
casos de uso significa que el diseflo esta ciertamente centrado en el usuario y basado alrede- 
dor de las interacciones del usuario con el sistema. Sin embargo, representar los requeri- 
mientos que no estan directamente ligados a los usuarios del sistema mediante casos de uso 
es dificil. Los casos de usos tienen ciertamente un papel en el analisis y diseflo orientado a 
objetos, pero necesitan ser complementados con otras tecnicas que nos permitan descubrir re- 
querimientos indirectos y no funcionales del sistema. 
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14.1 Objetos y clases 

En la actualidad los terminos «objeto» y «orientado a objetos» se aplican a diversos tipos de 
entidades, metodos de diseno, sistemas y lenguajes de programacion. Sin embargo, por lo ge- 
neral se acepta que un objeto es un encapsulamiento de la informacion, y esto se refleja en las 
siguientes definiciones de objeto y clase: 

Un objeto es una entidad que tiene un estadoy un conjunto de operaciones dejinidas 
que operan sobre ese estado. El estado se representa conto un conjunto de atributos del 
objeto. Las operaciones asociadas al objeto proveen servicios a otros objetos (clientes) 
que solicitan estos servicios cuando se requiere llevar a cabo algun cdlculo. 

Los objetos se crean conforme a una definition de clases de objetos. Una definition de 
ciases sirve como una pi an til la para crear objetos. Esta incluye las declaraciones de 
todos /os atributos y operaciones asociados con un objeto de esa clase. 

En U M L , una clase se representa como un rectangulo al cual se le han asignado un nom- 
bre y dos secciones. Los atributos del objeto se listan en la seccion superior. Las operaciones 
que estan asociadas con el objeto se listan en la seccion inferior. La Figura 14.2 ilustra esta 
notacion par utilizando una clase de objetos que modela a un empleado de una organizacion. 
En la notacion UML, el termino «operacion» es la especificacion de una accion: el termino 
«metodo» se utiliza para referirse a la implementacion de la operacion. 

La clase Employee define varios de los atributos que contienen informacion de los em- 
pleados, incluyendo su nombre y direccion, el numero de seguro social, el codigo de pago de 
impuestos, etcetera. Los puntos suspensivos (...) indican que existen mas atributos asociados 
con la clase y que no se muestran aqui. Las operaciones asociadas con el objeto sonjoin (que 
se llama cuando un empleado se une a la organizacion), leave (que se llama cuando un em- 
pleado abandona la organizacion), retire (que se llama cuando un empleado se convierte en 
pensionista) y changeDetails (que se llama cuando la informacion de un empleado requiere 
algunos cambios). 

Los objetos se comunican a traves de la solicitud de servicios (llamando a los metodos) de 
otros objetos y, si es necesario, intercambiando la informacion requerida para que ese servi- 



Employee 

name: string 
address: string 
dateOfBirth: date 
employeeNo: integer 
socialSecurityNo: string 
department: dept 
manager: employee 
salary: integer 

status: {current, left, retired) 
taxCode: integer 



join 0 
leave 0 
retire 0 

changeDetails Q 



Figura 14.2 Un 
objeto empleado. 
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cio se suministre. Las copias de la informacion necesaria para ejecutar el servicio y los re- 
sultados de laejecucion del servicio sepasancomo parametros. Algunos ejemplos de este es- 
tilo de comunicacion son: 

// Llama a un metodo asociado con un objeto bufer 

// que regresa ei siguiente valor en el bufer 

v = circula rBuffer.Get 0; 

// Llama al metodo asociado con un objeto 

//termostato que establece la temperatura que se mantendra 

thermostatsetTemp (20); 

En los sistemas basados en servicios las comunicaciones de los objetos se implementan 
directamente como mensajes de texto que los objetos intercambian. El objeto receptor 
analiza el mensaje, identifica el servicio y los datos asociados, y lleva a cabo el servicio so- 
licitado. Sin embargo, cuando los objetos coexisten en el mismo programa, las llamadas a 
los metodo s se implementan como llamadas a procedimientos o funciones en un lenguaje 
como C. 

Cuando las peticiones de servicios son implementadas siguiendo estavia, lacomunicacion 
entre los objetos es sincrona. Esto es, el objeto invocador espera a que la peticion del servi- 
cio se complete. Sin embargo, si los objetos se implementan como procesos concurrentes o 
hilos, la comunicacion es asincrona. El objeto invocador continua en operacion mientras que 
el servicio solicitado se ejecuta. Mas adelante en esta seccion, se explica como se implemen- 
tan los objetos como procesos concurrentes. 

Como se indico en el Capitulo 8, en la parte donde se describen los diferentes modelos de 
objetos posibles, las clases se pueden organizar mediante una generalizacion ojerarquia de 
herencia que muestra las relaciones entre las clases generates y mas especificas. La clase mas 
especifica concuerda completamente con la clase general, pero incluye informacion adicio- 
nal. En la notacion UML, la generalizacion se Indica mediante una flecha que apunta a la cla- 
se padre. En los lenguajes de programacion orientados a objetos, por lo regular la generali- 
zacion se implementautilizando el mecanismo de herencia. La clase hijaheredalos atributos 
y operaciones de la clase padre. 

La Figura 14.3 muestra un ejemplo de jerarquia de clases en el cual se ilustran las di- 
versas clases para Employee. Las clases inferiores de lajerarquia tienen los mismos 
atributos y operaciones que sus clases padre, y se les pueden agregar nuevos atributos y 
operaciones o modificar los de sus clases padre. Esto significa que el intercambio solo 
existe en un solo sentido. Si el nombre de la clase padre se utiliza en un modelo, esto im- 
plica que el objeto en el sistema se define ya sea como esa clase o como cualquiera de sus 
descendientes. 

La clase Manager de la Figura 14.3 tiene todos los atributos y operaciones de la clase Em- 
ployee, pero ademas tiene dos nuevos atributos que registran lospresupuestos controlados por 
el administrador y la fecha en la que el administrador fue solicitado para una tarea de admi- 
nistracion particular. De igual forma, la clase Programmercontienenuevos atributos que de- 
finen el proyecto en el que trabaja el programador y las capacidades que tiene. Los objetos de 
la clase Manager o Programmer se pueden utilizar en cualquier lugar en el que se requiera 
un objeto de la clase Employee. 

Los objetos que son miembros de una clase participan en las relaciones con otros objetos. 
Estas relaciones se modelan describiendo las asociaciones entre las clases. En U M L , las aso- 
ciaciones se denotan mediante una linea que une las clases, a la que se le puede agregar una 
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nota con informacion de la asociacion. Esto se ilustra en la Figura 14.4, que muestra la aso- 
ciacion entre los objetos de la clase Employee y los objetos de la clase Department y entre 
los objetos de la clase Employee y los de la clase Manager. 

La asociacion esunarelacionmuy general y amenudoseutilizaenU ML para indicar que 
un atributo del objeto es un objeto asociado, o que la implementacion de un metodo del ob- 
jeto depende del objeto asociado. Sin embargo, al menos en principio, cualquier clase de aso- 
ciacion es posible. Unade las asociaciones mas comunes es la agregacion que muestra la ma- 
nera en que los objetos estan compuestos de otros objetos. Vease el Capitulo 8 para una 
descripcion de este tipo de asociacion. 



14.1.1 Objetos concuirentes 

De forma conceptual, un objeto solicita un servicio de otro objeto enviandole un mensaje de 
«solicitud de servicio» a ese objeto. No es necesario que un objeto ejecute estos mensajes en 
forma secuencial y que espere hastacompletarun servicio solicitado. En consecuencia, el mo- 
delo general de interaccion de objetos les permite ejecutarse concurrentemente como proce- 
sos en paralelo. Estos objetos se ejecutan en la misma computadora o como objetos distri- 
buidos endiferentes maquinas. 
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En la practica, muchos de los lenguajes de programacion orientados a objetos tienen 
su propio modelo de ejecucion en serie en el cual las peticiones de los servicios a obje- 
tos se implementan de la misma forma en la que se llama a una funcion. Por lo tanto, cuan- 
do un objeto llamado the List se crea a partir de una clase de objetos normal, en Java 
escribimos: 

theList. append (17) 

Este llama al metodo append asociado con el objeto theList para anadirel elemento 17 
a theList, y la ejecucion del objeto que hace la llamada se suspende hasta que la opera- 
cion append se ha completado. Sin embargo, Java incluye un mecanismo muy simple 
(hilos) que nos permite crear objetos que se ejecuten al mismo tiempo. Los hilos se crean 
en Java utilizando la clase nativa Threat como clase padre en la declaracion de una 
clase. Los hilos deben incluir un metodo llamado run , el cual es inicializado por el run-time 
de Java cuando se crean los objetos definidos como hilos. Por lo tanto, es facil tomar un di- 
seno orientado a objeto e implementarlo de forma que los objetos sean procesos concu- 
rrentes. 

Existen dos clases de implementacion de objetos concurrentes: 

1. Servidores en los cuales el objeto se implementa como un proceso paralelo con 
metodos que corresponden a las operaciones definidas de los objetos. Los metodos 
inician su actividad en respuesta a un mensaje extemo y se ejecutan en paralelo con 
los metodos asociados a otros objetos. Cuando han completado su operacion, el 
objeto se suspende por si mismo y espera por las peticiones adicionales de los 
servicios. 

2. Objetos activos en los cuales el estado de los objetos cambia debido a la ejecucion de 
operaciones internas. El proceso que representa al objeto ejecuta continuamente estas 
operaciones, por lo que no se suspende por si solo. 

Los servidores son mas utiles en entornos distribuidos donde los objetos invocadores y los 
objetos invocados se ejecutan en diferentes computadoras. El tiempo de respuesta para el ser- 
vicio solicitado es impredecible; por lo tanto, siempre que seaposible, se debe disenarel sis- 
tema de tal forma que el objeto que solicita un servicio no tenga que esperar a que el servicio 
se complete. Tambien se pueden utilizar en una sola maquina en la cual a un servicio le lleve 
cierto tiempo completarse (por ejemplo, la impresion de un documento) y el servicio puede 
ser requerido por varios objetos diferentes. 

Los objetos activos se utilizan cuando un objeto necesita actualizar su propio estado en in- 
tervalos especificos. Esto es comun en sistemas de tiempo real donde los objetos se asocian 
a dispositivos de hardware que recolectan informacion del entorno del sistema. Los metodos 
del objeto permiten a otros objetos acceder a la informacion del estado. 

La Figura 14.5 muestra la manera en que un objeto activo se define e implementa en 
Java. Esta clase de objetos representa un transpondedor de un avion. Dicho transpon- 
dedor mantiene informacion de la posicion del avion utilizando un sistema de navega- 
cion via satelite. Puede responder a los mensajes de las computadoras para el control del 
trafico aereo. Suministra la posicion actual del avion como respuesta a la peticion del 
metodo givePosition. Este objeto se implementa como un hilo, donde un ciclo continuo en 
el metodo run incluye codigo para calcular la posicion del avion utilizando seflales de los 
satelites. 
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class Transponder extends Thread { 

Position currentPosition ; 
Coords Cl,c2 ; 
Satellite sat 1, satt ; 
Navigator theNavigator ; 

public Position givePosition 0 



while (true) 
( 

cl »sst1 .position 0 ; 
C2 * ss&position 0 ; 

currentPosition — theNavtgator.compute (cl, c2) ; 



14.2 Un proceso de diseno orientado a objetos 



En esta seccion se ilustra el proceso de diseno orientado a objetos por medio del desarrollo 
de un ejemplo de diseno para el software de control que esta incrustado en una estacion me- 
teorologica automatizada. Como se indico en la introduccion, existen varios metodos de di- 
seno orientados a objetos sin que exista un «mejor» metodo o proceso de diseno. El proceso 
que aqui se muestra es un proceso general que incorpora las actividades comunes de muchos 
de los procesos de diseno orientados a objetos. 

El proceso general que aqui se utiliza para el diseno orientado a objetos tiene varias 
etapas: 

1. Comprendery definirel contexto y los modos de utilizacion del sistema. 

2. Disenar la arquitectura del sistema. 

3. Identificar los objetos principales en el sistema. 

4. Desarrollar los modelos de diseno. 

5. Especificar las interfaces de los objetos. 

A proposito, este proceso no se muestra como un diagrama de proceso simple, puesto que 
esto implicaria la existencia de actividades detalladas llevadas a cabo en secuencia. De hecho, 
todas las actividades anteriores se pueden ver como actividades entrelazadas que influyen en- 
tre si. Los objetos se identifican y las interfaces se especifican completa o parcialmente en el 
momento de definir la arquitectura del sistema. En el momento de elaborar los modelos de 
objetos, estas definiciones de los objetos se refinan y pueden implicar un cambio en la arqui- 
tectura del sistema. 



{ 

return currentPosition ; 

) 



public void run 0 
{ 



Figura 14.5 
Implementacionde 
un objeto adivo 
utilizando 

subprocesos de Java. 



} 

) 

} //Transponder 
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Mas adelante, en esta seccion, se expondra de forma separada cada una de estas etapas del 
proceso de diseno. Sin embargo, nodebe suponerse que el diseno esun proceso sencilloybien 
estructurado. En realidad, un diseno se desarrolla proponiendo soluciones y retinando estas 
soluciones, al disponer de mas informacion. Inevitablemente, se tendra que regresar y reto- 
mar los problemas cuando estos surjan. Algunas veces, tendra que explorar las opciones en 
detalle para ver si funcionan: otras veces habra que prescindir de los detalles y retomarlos mas 
adelante era el proceso. 

Estas actividades del proceso se ilustran mediante un ejemplo de un diseno orientado a ob- 
jetos. Este ejemplo es parte de un sistema para trazar mapas meteorologicos, utilizando datos 
meteorologicos recogidos de forma automatica. El detalle de los requerimientos para este sis- 
tema abarcaria varias paginas. Sin embargo, la arquitectura del sistema completo se puede 
desarrollar a partirde una descripcion relativamente breve del sistema: 

Se requiere un sistema para generar mapas meteorologicos a partir de la recogida pe- 
riodica de los datos de estaciones meteorologicas remotas y automdticasy datos de 
otras fuentes, cotno observatorios meteorologicos, globos v satelites. Las estaciones 
meteorologicas transmiten sus datos a la computadora del area en respuesta a una pe- 
tition de esa mdquina. 

El sistema de computo del area valida los datos recogidos e Integra los datos de diver- 
sas fuentes. Los dalos integrados se guardan y, utilizando datos de este archivoy una 
base de datos de mapas digitalizados. se crea un conjunto local de mapas meteorolo- 
gicos. Los mapas se pueden imprimir para su distribution en una impresora de mapas 
de proposito especial y pueden ser visualizados en pantalla en diferentes formatos. 

Esta descripcion muestra que parte del sistema completo se refiere a la recogida de datos, 
parte a la integracion de los datos de diversas fuentes, parte a archivar estos datos y parte a 
crear mapas meteorologicos. La Figura 14.6 ilustra una posible arquitectura del sistema que 
se deriva de esta descripcion. Esta es una arquitectura de capas (descrita en el Capitulo 11) 
que refleja las diversas etapas de procesamiento en el sistema, principalmente recogida de da- 
tos, integracion de datos, archivado de datos y generacion de mapas. En este caso, una arqui- 
tectura de capas es apropiada debido a que cada etapa depende solo del procesamiento de la 
etapa previa a esta operacion. 



Figura 14.6 
Arquitectura de 
capas para un 
sistema de creacion 
jde mapas 
meteorologicos. 
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En la Figura 14.6 se muestran las diferentes capas y se incluye el nombre de la capa en un 
slmbolo derepresentacionde paquetes enU M Lque sehadenotado como un subsistema. Un 
paquete en U M L representa una coleccion de objetos y otros paquetes. Aqui se ha utilizado 
para mostrar que cada capa incluye otros componentes. 

En la Figura 14.7 se ha extendido este modelo de arquitectura abstracta para mostrar los 
componentes de los subsistemas. Estos siguen siendo muy abstractos y se han derivado de la 
informacion en la descripcion del sistema. A partir de ahora, el ejemplo de diseno se centra 
en el subsistema de la estacion meteorologica que es parte de la capa de recogida de datos. 



14.2.1 Contexto del sistema y modelos de utlllzacldn 

La primera etapa en el proceso de diseno de software es comprender las relaciones entre el 
software que se esta disenando y el entorno externo. Comprender esto ayuda a decidir como 
suministrar la funcionalidad requerida al sistema y como estructurar este para que se comu- 
nique efectivamente con su entorno. 

El contexto del sistema y el modelo de utilizacion del sistema representan dos modelos 
complementarios entre un sistema y su entorno: 

1. El contexto del sistema es un modelo estatico que describe a los otros sistemas de su 
entorno. 

2. El modelo de utilizacion del sistema es un modelo dinamico que describe como el sis- 
tema interactuacon su entorno. 

El modelo de contexto de un sistema se representa utilizando asociaciones (vease la Figu- 
ra 14.4) donde, esencialmente, se produce un diagrama de bloques sencillo de la arquitectu- 
ra del sistema complete 

Esto se puede extender representando un modelo del subsistema utilizando paquetes en 
U M L como se muestra en la Figura 14.7. Esto ilustra que el contexto de la estacion meteoro- 
logica esta dentro de un sistema involucrado en la recoleccion de datos. Tambien muestra otros 
subsistemas que componen el sistema de trazado de mapas meteorologicos. 
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Figura 14.8 Casos 
de uso de la 
estacion 
meteorologica. 




Cuando se modelan las interacciones de un sistema con su entorno, se debe utilizar un enfo- 
que abstracto que no incluya mucho detalle de esas interacciones. El enfoque que se propone en 
U M L es desarrollar un modelo de casos de uso donde cada caso de uso representa una interac- 
cion con el sistema. En los modelos de caso de uso (descritos tambien en el Capitulo 7), cada inter- 
accion posible se enuncia en una elipse y la entidad externa implicada en la interaccion se repre- 
senta mediante una figura estilizada. En el caso del sistema de la estacion meteorologica esta 
entidad externa no es un humano sino el sistema de procesamiento para los datos meteorologicos. 

En la Figura 12.8 se presentaun modelo de caso de uso para la estacion meteorologica. Este 
muestra que la estacion meteorologica interactua con las entidades externas para iniciarse o para 
apagarse, para informar de los datos meteorologicos recogidos y para calibrary probar los ins- 
trumentos. 

Cada uno de estos casos de uso se describe utilizando una descripcion en lenguaje natural 
sencillo. Esto ayuda a los disenadores a identificar los objetos en el sistemay les permite com- 
prender lo que hara el sistema. Aqui se utiliza un formulario estandarizado para describir e iden- 
tificar claramente la informacion que se intercambia, como se inicia la interaccion, etcetera. 
Esto se muestra en la Figura 14.9 donde se describe el caso de uso Informar de la Figura 14.8. 



Sisteme Estacion meteorologica. 

Caso ile ino Informar. 



Adam Sistema de recogida de datos meteorologicos, estacion meteorologica. 



Datos 



Estimulo 



La estacion meteor old gica envia un resumen de tos datos meteorologicos 
recogidos de (os instrumentos en el periodo de recogida al sistema de recogida 
de datos meteorologicos. Los datos enviados son tos valores maximo, minimo y 
promedio de las temperaturas del suelo y del aire; tas presiones del aire 
maxima, minima y promedio; las velocidades del viento maxima, minima y 
promedio; la tkrvia total y ta direccion del viento tomada cada cinco minutos. 

El sistema de recogida de datos meteorologicos establece un vinculo por medio 
del modem con la estacion meteorologica y solicita la transmision de los datos. 

Un resumen de los datos se envia al sistema de recogida de datos 



Figura 14.9 
Descripcion del caso 
de uso Informar. 
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La descripcion del caso de uso ayuda a identificar los objetos y operaciones en sistema. De 
la descripcion del caso de uso Inf ormar, es obvio que se requieren objetos que representen los 
instrumentos que recogen los datos meteorologicos, asi como el objeto que represente el re- 
sumen de dichos datos. Es necesario definir las operaciones que representen la solicitud y el 
envio de datos meteorologicos. 



14.2.2 Diseno de la arqultectura 

Una vez que se han definido las interacciones entre el sistema de software que se esta dise- 
flando y el entorno del sistema, se puede utilizar esta informacion como base para disenar la 
arquitectura del sistema. Por supuesto, es necesario combinar esto con el conocimiento ge- 
neral de los principios de diseno arquitectonico y con el conocimiento mas detallado del do- 
minio. 

La estacion meteorologica automatizada es un sistema relativamente sencillo y su arqui- 
tectura se puede representar como un modelo encapas. Esto se ilustraen laFigura 14.10 como 
un arbol de paquetes de U M L dentro del paquete mas general Estacion meteorologica. Note 
que aqui se ha utilizado la notacion en UML (texto en cuadros con unapestafia en la esqui- 
na) para proveer informacion adicional. 

Las tres capas en el software de la estacion meteorologica son: 

1 . La capa de interfaz, que comprende todas las comunicaciones con otras partes del sis- 
tema y el suministro de las interfaces extemas del sistema. 

2. La capa de recogida de datos, que se ocupa de administrar la recogida de datos de los 
instrumentos y de resumir los datos meteorologicos antes de la transmision al sistema 
de mapas. 

3 . La capa de instrumentos, que comprende el encapsulamiento de todos los instrumen- 
tos utilizados en la recogida de los datos acercade las condiciones meteorologicas. 

En general, se debe tratar de descomponer un sistema de tal forma que las arquitecturas 
sean lo mas sencillas posible. Una regla que siempre funciona es que no debe haber mas de 
siete entidades fundamentales en un modelo arquitectonico. Cada una de estas entidades se 
puede describir independientemente, pero, por supuesto, se debe dejar al descubierto la es- 
tructurade las entidades, como se muestra en la Figura 14.7. 
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14.2.3 Identification de objetos 

En esta etapa del proceso de diseno ya tuvo que haber formulado algunas ideas de los obje- 
tos esenciales del sistema que se esta disenando. En el sistema de la estacion meteorologica, 
esta claro que los instrumentos son objetos y que se necesita al menos un objeto en cada uno 
de los niveles de la arquitectura. Esto refleja un principio general, el cual senala que los ob- 
jetos tienden a emerger durante el proceso de diseno. Sin embargo, por lo general, hay que 
buscar y documentar otros objetos que pudieran ser relevantes. 

Aunque esta seccion se hadenominado identificacion de objetos, en lapractica este proce- 
so se refiere a la identificacion de clases. El diseno se describe en funcion de estas clases. De 
forma inevitable, se tienen que retinar las clases identificadas de forma inicial y volver a esta 
etapa del proceso conforme se vaya obteniendo una comprension mas profunda del diseno. 

Se han hecho varias propuestas de como identificar las clases: 

1. Utilizarun analisis gramatical de la descripcion en lenguaje natural del sistema. Los 
objetos y los atributos son sustantivos; las operaciones o servicios son verbos (Abbott, 
1983). Este enfoque se considero en el metodo HOOD para el diseno orientado a ob- 
jetos (Robinson, 1 992) que se utiliza ampliamente en la industria aeroespacial europea. 

2. Utilizar entidades tangibles (cosas) en el dominio de aplicacion como aviones, papeles 
como administrador, eventos como una peticion, interacciones como reuniones, ubica- 
ciones como oficinas, unidades organizacionales como companias, etcetera (Shlaery 
Mellor, 1998; Coady Yourdon, 1990; Wirfs-Brock etai, 1990). Esto sedebe comple- 
mentar identificando estructuras de almacenamiento (estructuras abstractas de datos) en 
el dominio de la solucion, las cuales podrian requerirse para apoyar a estos objetos. 

3. Utilizarun enfoque de comportamiento en el cual el disefladorprimero comprende el 
comportamiento total del sistema. Los diversos comportamientos se asignan a distin- 
tas partes del sistema para asi comprender quien inicia y participa en estos comporta- 
mientos. Los participantes que desempenan papeles importantes se identifican como 
objetos (Rubin y Goldberg, 1992). 

4. Utilizar un analisis basado en escenarios en el cual se identifican y analizan en su mo- 
menta varios escenarios de la forma de utilizar el sistema. Puesto que cada escenario se 
analiza, el equipo responsable del analisis debe identificar los objetos, atributos y ope- 
raciones requeridos. Para ayudar a este enfoque basado en escenarios existe un metodo 
efectivo de analisis denominado tarjetas CRC en el cual los analistas y disenadores se 
encargan de identificar las actividades de los objetos (Becky Cunningham, 1989). 

Estos enfoques ayudan en el inicio de la identificacion de objetos. En la practica, diversas 
fuentes de conocimiento se utilizan para descubrir objetos y clases. Los objetos y las opera- 
ciones que se identifican inicialmente de la descripcion informal del sistema pueden ser un 
punto de partidapara el diseno. La informacion adicional del conocimiento del dominio de 
aplicacion o del analisis del escenario se utiliza para refinar y extender los objetos iniciales. 
Esta informacion se recoge de los documentos de requerimientos, de las discusiones con los 
usuarios y de un analisis de los sistemas existentes. 

Aqui se ha utilizado un enfoque hibrido para identificar los objetos de la estacion meteo- 
rologica. No se cuenta con suficiente espacio para describir a todos los objetos; sin embar- 
go, enlaFigura 14.11 se muestran cinco clases de objetos: Ground Thermometer, Anemo- 
meter y Barometer representan objetos del dominio de la aplicacion, y Weatherstation y 
WeatherData provienen de la descripcion del sistema y de la descripcion del escenario (ca- 
sos de uso). 
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Estos objetos se relacionan con los diversos niveles de la arquitectura del sistema. 

1. La clase Weatherstation provee la interfazbasicade la estacion meteorologica con su 
entorno. Por lo tanto, sus operaciones reflejan las interacciones que se muestran en la 
Figura 14.8. En este caso se utiliza una sola clase para encapsular todas estas interac- 
ciones, pero en otros disenos puede ser mas apropiado utilizar varias clases para pro- 
veer la interfaz del sistema. 

2. La clase de objetos WeatherData encapsula el resumen de datos de los diversos ins- 
trumentos en la estacion meteorologica. Sus operaciones asociadas se refieren a la re- 
cogida y resumen de los datos requeridos. 

3. Las clases GroundThermometer, Anemometer y Barometer se relacionan directa- 
mente con los instrumentos del sistema. Reflejan las entidades de hardware tangibles 
en el sistema y las operaciones se refieren al control de ese hardware. 

En esta etapa del proceso de diseno, se utiliza el conocimiento del dominio de la aplicacion 
para identificara los objetos y servicios adicionales. En este caso, se sabe que a menudo las es- 
taciones climatologicas se localizan en lugares remotos y estas incluyen diversos instrumentos 
que algunas veces funcionan mal. Los fallos en los instrumentos deberan informarse de forma 
automatica. Esto implica que son necesarios los atributos y operaciones para verificar el fun- 
cionamiento correcto de los instrumentos. Obviamente, existen muchas estaciones climatolo- 
gicas remotas. Por lo tanto, se necesita una forma de identificar los datos recogidos de cada es- 
tacion, por lo que cada estacion climatologicadebe tener su propio identificador. 

En este ejemplo, se ha decidido no hacer objetos activos a los objetos asociados con cada 
instrumento. La operacion collect en WeatherData hace una llamada a los objetos instru- 
mento para realizar las lecturas cuando estas se requieran. Los sujetos activos incluyen su pro- 
pio control y, en este caso, esto significa que cada instrumento decide cuando llevar a cabo 
las lecturas. Sin embargo, la desventaja de esto es que, si se tomo la decision de cambiar los 
tiempos de recogida de datos o si las diversas estaciones climatologicas recogen datos de for- 
ma diferente, tienen que introducirse nuevas clases de objetos. Al hacer que los objetos ins- 
trumento realicen lecturas bajo peticion, cualquier cambio en laestrategia de recogida se pue- 
de implementar facilmente sin cambiar los objetos asociados con los instrumentos. 
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14.2.4 Modelos de diseno 

Los modelos de diseno muestran los objetos o clases en un sistema y, donde sea apropiado, 
los diferentes tipos de relaciones entre estas entidades. Los modelos de diseno son esencial- 
mente el diseno mismo. Son el puente entre los requerimientos y la implementacion del sis- 
tema. Esto significa que existen requerimientos en conflicto en estos modelos. Tienen que ser 
abstractos con el fin de que el detalle innecesario no oculte las relaciones entre ellos y los re- 
querimientos del sistema. Sin embargo, tambien tienen que incluir suficiente detalle para que 
los programadores tomen las decisiones de implementacion. 

En general, le puede dar la vuelta a este conflicto desarrollando diversos modelos en di- 
versos niveles de detalle. Si existen vinculos cercanos entre los ingenieros de requerimientos, 
los diseftadores y los programadores, lo unico que se requiere son modelos abstractos. Las de- 
cisiones del diseno especifico se construyen durante la implementacion del sistema. Si los vin- 
culos entre los especificado res del sistema, los diseftadores y los programadores son indirec- 
tos (por ejemplo, cuando un sistema se disefta en una parte de la organizacion pero se 
implementa en otra), se requieren modelos mas detallados. 

Un paso importante en el proceso de disefto es decidirque modelos de disefto son necesa- 
rios y el nivel de detalle de estos modelos. Esto tambien depende del tipo de sistema que se 
este desarrollando. Un sistema de procesamiento secuencial de datos se disefta de forma di- 
ferente de un sistema dedicado en tiempo real, por lo que utiliza distintos modelos de disefto. 
Existen muy pocos sistemas donde todos los modelos son necesarios. Minimizar el numero 
de modelos que se produce reduce los costes de disefto y el tiempo requerido para completar 
el proceso. 

Existen dos tipos de modelos de disefto para describir un disefto orientado a objetos: 

1. Modelos estaticos que describen la estructura estatica del sistema en terminos de las 
clases del sistema y sus relaciones. Las relaciones importantes que se documentan en 
estaetapa son de generalizacion, utiliza/utilizado-pory de composicion. 

2. Modelos dinamicos que describen la estructura dinamica del sistema y que mues- 
tran las interacciones entre los objetos del sistema (no entre las clases). Las interac- 
ciones que se documentan incluyen la secuencia de servicios solicitados por los ob- 
jetos y la forma en que el estado del sistema se relaciona con estas interacciones de 
objetos. 

U M L provee 12 modelos estaticos y dinamicos que pueden serutilizados en el documen- 
to de disefto. No se cuenta con suficiente espacio para abordar a todos ellos y no todos son 
apropiados para el ejemplo de la estacion climatologica. Los modelos que se discutiran en esta 
seccion son: 

1. Los modelos de subsistemas que muestran las agrupaciones logicas de objetos en sub- 
sistemas coherentes. Estos se representan utilizando una forma de los diagramas de 
clase en el que cada subsistema se muestra como un paquete. Los modelos de subsis- 
temas son modelos estaticos. 

2. Los modelos de secuencia que muestran la secuencia de interacciones de los objetos. 
Estos se representan utilizando una secuencia U M L o un diagrama de colaboracion. 
Los modelos de secuencia son modelos dinamicos. 

3. Los modelos de mdquinas de estado que muestran como los objetos individuales cam- 
bian su estado en respuesta a los eventos. Esto se representa en U M L utilizando dia- 
gramas de estado los cuales son modelos dinamicos. 
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Ya se han expuesto otros modelos que pueden utilizarse para diseno y analisis orientado a 
objetos. Los modelos de casos de uso muestran las interacciones con el sistema (Figura 14.8 
y Figuras 7.6 y 7.7 del Capitulo 7); los modelos de objetos describen las clases (Figura 14.2); 
los modelos de generalizaciony herencia (Figuras 8.10,8.1 1 y 8. 12 del Capitulo 8) muestran 
como las clases pueden sergeneralizacionesdeotras clases, y los modelos de agregacion (Fi- 
gura 8.13) muestra como podemos describir colecciones de objetos. 

La Figura 14.12 muestra los objetos de los subsistemas de la estacion meteorologica. En 
estaetapadel proceso de diseno se utilizael conocimiento del dominio de la aplicacion para 
identificar a los objetos y servicios adicionales. En este modelo tambien se muestran algunas 
asociaciones. Por ejemplo, el objeto CommsControler esta asociado con el objeto Wea- 
therstation, y este esta asociado con el paquete Data collection. Esto significa que el objeto 
esta asociado con uno o mas objetos de este paquete. Un modelo de paquetes mas un mode- 
lo de clases dan una descripcion de las agrupaciones logicas del sistema. 

Un modelo de subsistemas es un modelo estatico util que nos muestra como puede estar 
organizado el diseno de forma logica agrapando objetos. En la Figura 14.7 quedo reflejado 
este tipo de modelos, que muestra los subsistemas del sistema de mapas meteorologicos. Los 
paquetes U M L contienen las construcciones de encapsulacion y no se reflejan directamente 
sobre las entidades del sistema que se jmplementa. Sin embargo, pueden verse reflejadas en 
construcciones de estructuras tales como las librerias Java. 

Los modelos de secuencia son modelos dinamicos que documentan, para cada modo de 
interaccion, la secuencia de interacciones que tienen lugarentre los objetos. La Figura 14.13 
es un ejemplo de modelo de secuencia que muestra las operaciones involucradas en la reco- 
gida de datos de una estacion meteorologica. En un modelo de secuencia: 

1 . Los objetos involucrados en la interaccion estan ordenados horizontal mente con una 
linea vertical vinculada a cada objeto. 
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2. El tiempo se representa verticalmente, por lo que este avanza hacia abajo sobre las li- 
neas punteadas. Por lo tanto, en el modelo, la secuencia de operaciones se puede leer 
facilmente. 

3. Las interacciones entre los objetos se representan por flechas etiquetadas que vincu- 
lan a las lineas verticales. Estos no son datos que fluyen, sino que representan mensa- 
jes o eventos que son fundamentales para la interaccion. 

4. Los rectangulos delgados sobre la linea de vida del objeto representan el tiempo en el 
cual el objeto es el que tiene el control del sistema. Un objeto inicia el control en la 
parte superior de este rectangulo y libera el control a otro objeto en la parte inferior 
delmismo. Si existeunajerarquiade llamadas, el control no se libera hasta que sehaya 
completado el ultimo retorno a la llamada del metodo inicial. 

Cuando se documenta un diseno, se debe producirun modelo de secuencia para cada inter- 
accion significativa. Si se ha desarrollado un modelo de casos de uso, entonces se debera te- 
ner un modelo de secuencia para cada caso de uso identificado. 

La Figura 14.13 muestra la secuencia de interacciones cuando el sistema extemo de traza- 
do de mapas solicita datos a la estacion meteorologica. Este diagrama se lee como se mues- 
tra a continuacion: 

1. Un objeto que es una instanciade Com msController (:CommsController) recibe una 
peticion de su entorno para enviar un informe meteorologico . Confirma que recibe la 
peticion. La flecha con media punta indica que el emisordel mensaje no espera una 
contestacion. 

2. Este objeto envia un mensaje aun objeto que es una instancia de Weatherstation para 
crearun informe meteorologico. La instancia de CommsControlerentonces se sus- 
pende a si misma (su cuadro de control termina). El estilo de la cabeza de la flecha uti- 
lizada indica que la instancia del objeto Co m msCo nt rol I e r y la instancia del objeto 
Weatherstation son objetos que se ejecutan al mismo tiempo. 

3. El objeto que es una instanciade Weatherstation envia un mensaje al objeto Weather- 
Data para resumir los datos meteorologicos. En este caso, el estilo diferente de laspun- 
tas de flecha utilizadas indica que la instancia de Weatherstation espera una respuesta. 



Figura 14.13 
Secuencia de las 
operaciones de 
recogida de datos. 
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4. Se realiza el resumeny el control regresa al objeto Weathers tat ion. Las flechaspun- 
teadas indican un retorno del control. 

5. Este objeto envia un mensaje a CommsController solicitandole transferir los dalos al 
sistemaremoto. Entonces, el objeto Weatherstation se suspendeasimismo. 

6. El objeto CommsController envia el resumen de los datos al sistema remoto, recibe 
una aceptacion y se suspende a si mismo esperando la siguiente solicitud. 

En el diagrama de secuencia se puede verque los objetos Com msControllery Weather- 
station son procesos concurrentes en los que la ejecucion se puede suspendery reiniciar. En 
lo esencial, la instancia del objeto CommsController escucha los mensajes del sistema ex- 
temo, decodinca estos mensajes e inicia las operaciones de la estacion meteorologica. 

Los diagramas de secuencia se utilizan para modelar el comportamiento combinado de un 
grupo de objetos, pero tambien son utiles para resumir el comportamiento de un solo objeto 
como respuesta a los diversos mensajes que puede procesar. Para hacer esto, se utiliza un mo- 
delo de maquinas de estado que muestra como la instancia del objeto cambia de estado de- 
pendiendo de los mensajes que reciba. U M L utiliza diagramas de estado, inventados por Ha- 
re! (Harel, 1987) para describir los modelos de maquinas de estado. 

LaFigural4.14esun diagrama de estado para el objeto Weatherstation que muestra como 
responde a la peticion de varios servicios. 

Este diagrama se puede leer como se muestra a continuacion: 

1. Si el estado del objeto es «Shutdown», entonces solo puede responder a un men- 
saje startupO- Despues se mueve a un estado donde espera por mensajes adiciona- 
les. La flecha sin etiqueta con la bola negra indica que «Shutdown» es el estado 
inicial. 

2. En el estado «Waiting», el sistema espera por mensajes adicionales. Si se recibe un 
mensaje shutdown 0, el objeto regresa al estado apagado. 

3. Si se recibe un mensaje reportWeatherO, el sistema se mueve a un estado de resumen 
y luego, cuando el resumen se completa, se mueve aun estado de transmision, donde 
la informacion se transmite a traves del CommsController. Despues regresa a un es- 
tado de espera. 



Flgura 14.14 

Diagrama de estado 
para Weatherstation. 
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4. Si se recibe un mensaje calibrate)), el sistema se mueve a un estado calibracion («Ca- 
lfbrate»), despues aun estado de praeba («Testing») y, por ultimo, al estado de trans- 
mision ( «Tra n sm i tt i n g» ) antes de regresar al estado de espera («Waiting»). Si se reci- 
be un mensaje test(), el sistema se mueve directamente al estado de prueba. 

5. Si se recibe una senal de reloj, el sistema se mueve a un estado de recoleccion, donde 
se recogen los datos de los instrumentos. Cada instrumento esta configurado para re- 
coger sus datos. 

Por lo general, no es necesario elaborar un diagrama de estado para todos los objetos que 
se hayan definido. Muchos de los objetos de un sistema son relativamente sencillos, y 
un modelo de maquina de estado no ayudaria a los implementadores a comprender estos 
objetos. 

14.2.5 Especlflcaclon de la Interfaz de los objetos 

Una parte importante de cualquier proceso de diseno es la especificacion de las interfaces en- 
tre los diferentes componentes del diseno. Es necesario identificar las interfaces para que los 
objetos y otros componentes se puedan diseftar en paralelo. Una vez que la interfaz se ha es- 
pecificado, los desarrolladores de otros objetos pueden suponer que la interfaz sera imple- 
mentada. 

Los disenadores deben evitar la informacion de representacion de la interfaz en el diseno 
de la interfaz. En su lugar, se debe ocultar la representacion y se deben proveer las operacio- 
nes de los objetos para accedery actualizar los datos. Si la representacion esta oculta, se pue- 
de cambiar sin afectar a los objetos que utilizan estos atributos. Esto conduce a un diseno que 
es inherentemente mas facil de mantener. Por ejemplo, una representacion en forma de vec- 
tor de una pila se puede cambiar por una representacion en forma de lista sin afectar a otros 
objetos que usen la pila. En contraste, es frecuente mostrar los atributos en un modelo de di- 
seno estatico, ya que este es el modo mas conciso de ilustrar las caracteristicas esenciales de 
los objetos. 

Esta no es necesariamente una relacion 1:1 entre los objetos y las interfaces. Los mismos 
objetos pueden tener varias interfaces que son puntos de vista de los metodos que proveen. 
Esto se permite en Java de forma directa donde las interfaces se declaran independientemen- 
te de los objetos, y los objetos «implementan» las interfaces. De igual forma, se puede acce- 
der a un grupo de objetos a traves de una sola interfaz. 

El diseno de interfaces de objetos comprende la especificacion del detalle de la interfaz 
para un objeto o un grupo de objetos. Esto significa definir las firmas y semantica de los ser- 
vicios proporcionados por los objetos o porun grupo de objetos. Las interfaces se especifican 
en U M L utilizando la misma notacion que en los diagramas de clases. Sin embargo, no exis- 
te una seccion de atributos, y el estereotipo en U M L <interfaz> se debe incluir en la parte del 
nombre. 

Un enfoque alternativo consiste en utilizarun lenguaje de programacion para definir la in- 
terfaz. Esto se ilustra en la Figura 14.15, que muestra la especificacion de la interfaz en Java 
para la estacion meteorologica. Si las interfaces sonmascomplejas, este enfoque es mas efec- 
tivo debido a que las herramientas de verificacion de sintaxis en el compilador se utilizan para 
descubrir errores e incongruencias en la descripcion de la interfaz. La descripcion en Java 
muestra que algunos metodos pueden tomar un numero de parametros diferente. Por lo tan- 
to, el metodo apagar se puede aplicar a la estacion como un todo si esta no tiene parametros 
o puede apagar un solo instrumento. 
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Despues de haber lomado una decision para desarrollar un sistema como el sistema de reco- 
gida de datos meteorologicos, es inevitable que se hagan propuestas de cambios. Una venta- 
ja importante de un enfoque orientado a objetos para el diseno es que simplifica el problema 
de hacer cambios a dicho diseno. Larazon de estoesque la representacion del estado del ob- 
jeto no influye en el diseno. Cambiar los detalles internos de un objeto no afecta a ningun otro 
objeto del sistema. Mas aun, debido a que los objetos estan debilmente acoplados, por lo re- 
gular es sencillo introducir nuevos objetos sin efectos importantes en el resto del sistema. 

Para ilusirar la robustez del enfoque orientado a objetos, supongamos que a cada estacion 
meteorologica se le agregan las capacidades de un sistema de supervision de la contamina- 
cion. Esto implica agregaruna metricade la calidad del aire paracalcular la cantidad de di- 
versos contaminantes en la atmosfera. Las lecturas de la contaminacion se transmiten al mis- 
mo tiempo que los datos meteorologicos. Para modificar el diseno se deben hacer los 
siguientes cambios: 

1. Debe introducirse una clase de objetos denominada Ail Quality como parte de 
Weatherstation al mismo nivel que WeatherData. 

2. Se debe agregar a Weatherstation unaoperacion reportAirQualityparaenviarlain- 

formacion de la contaminacion a la computadora central. El software de control de la 
estacion meteorologica se debe modificar para que las lecturas de la contaminacion se 
recojan automaticamente cuando lo solicite el objeto de alto nivel Weatherstation. 

3. Se deben agregar los objetos que representan a los tipos de instrumentos de supervi- 
sion de la contaminacion. En este caso, se pueden medir los niveles de oxido nitrico, 
humo y benzeno. 



Flgura 14.15 

Descripcion en Java 
de la interfaz de la 
estacion 
meteorologica. 
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Figura 14.16 
Nuevos objetos para 
ayudar a la 
supervision de la 
contaminacion. 
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Los objetos de supervision de la contaminacion estan encapsulados en un paquete diferente 
llamado Instrumentos para supervisar la contaminacion. Este tiene asociaciones con Air- 
Quality y WeatherSation, pero no con los objetos de WeatherData. La Figura 14.16 muestra 
Weatherstation y los nuevos objetos agregados al sistema. Ademas de los cambios en nive- 
les altos del sistema (Weatherstation) no se requiere ninguno mas en el software de los ob- 
jetos de la estacion meteorologica. La adicion de la recogida de los datos de contaminacion 
no afecta de ninguna forma a la recogida de datos meteorologicos. 



PUNTOS CLAVE 

• El d iseno orientado a objetosesun medio para disenar software de tal forma que los componentes del dise- 
ho representen objetos con su estado privado y operaciones propias en Lugar de funciones. 

• Un objeto debe tener operaciones constructory de inspection que permitan que su estado se inspeccione y 
modifique. El objeto suministra servicios (operaciones que utilizan informacion del estado) a otros objetos. 
Los objetos se crean en tiempo de ejecucion utilizando una especif icacidn en una definicion de clases. 

Los objetos se implementan de manera secuencia! o concurrente. Un objeto concurrente puede ser un objeto 
pasivo cuyo estado solo se cambia a traves de su jnterfaz o un objeto activo que cambia su propio estado sin 
intervencion externa. 

• El Lenguaje Unificado de Modelado (UML) suministra un conjunto de notaciones diversas que se pueden uti- 
lizar para documentar un diseno orientado a objetos. 

• El proceso de un d iseno orientado a objetos incluye actividades para disenar la arquitectura del sistema, iden- 
tificar los objetos en el sistema, describir el diseno utilizando diversos mode los de objetos y documentar las 
interfaces de objetos. 
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* Duarte in praceso de diseno orientado a utjutus se produce ira ffsn variedad de modelos, eribe los que se 
encuenhan Ids nradebs estaticos (modeks de dases, de generalization, de asoclaclon) y dlnamlcos (mode- 
los de secuenda y de maquina de estados). 

* I as h AufCcKses da dbjetaa defaan daftvsa da ha na pvedsa pcia qu a pu eri an ser ulBfiidas por obos optetaSL 
Rara documentar bs Menaces de dujetas se utfiza in ler^jaje de programacion oomo java. 

* Una vantaja tun ta n b del diseno orientado a dbjetas es que stnp Bc a fa evolution del stetema 



lecturas adi cio n ales f t I A B K S M i i A i i M H B H H M f 1 i S N 

Applying UML and Patterns: An introduction to Object-Oriented Analysis and Design and the Unified Process, 2nd 
ed, Una buena introduccion sobre el uso de UML dentro de un proceso de diseno orientado a objetos. Incluye los 
patrones de diseno tratados en el Capitulo 18. (C. Larman, 2001, Prentice Hall.) 

The Unified Modeling Language User Guide. Un texto excepcional sobre UMLysu utilizacion en la descripcion de di- 
senos orientados a objetos. Existen dos textos asociados; uno es un manual de referenda de UML, y el otro propo- 
ne un proceso de desarrollo orientado a objetos. (G. Booch era/., 1999, Add i son-Wesley.) 

A mediados de 2003 se termino un nuevo estandar de UML (UML 2.0), pero de momento (os libros no han reflejado 
estos cambios. Es de esperar que en 2005 esten disponibles ediciones que incorporen este estandar. 

Hay un cantidad inmensa de introducciones y tutoriales de UML en la web. En la pagina web de libro he incluido al- 
gunos enlaces. 



EJERCICIOS M I I M i M &w mHHBHLHElMi 

141 Explique por que adoptar un enfoque de diseno basado en objetos con acoplamiento debil que oculta in- 
formacion acerca de su representacion, conduce a un diseno que puede ser facilmente modificable. 

142 Explique la diferencia entre un objeto y una clase, utilizando ejemplos. 

14.3 £En que circunstancias seria apropiado desarrollar un diseno donde los objetos se ejecuten al mismo 
tiempo? 

144 Utilizando lanotacion grafica de UML para clases, disene las siguientes clases identificando los atributos 
y las operaciones. Utilice la experiencia propia para decidir sobre los atributos y operaciones que estan 
asociadas a estos objetos: 

• un telefono; 

• una impresora para una computadora personal; 

• un sistema estereo personal; 

• una cuenta bancaria; 

• un catalogo de biblioteca. 

14.5 Desarrolle el diseno detallado de la estacion meteorologica proponiendo descripciones de la interfazde 
los objetos mostrados en la Figura 14.11. Este se puede expresar en java, en C++ o en UML. 
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14.6 Desarrolle el diseho de la estacion meteoroldgica para mostrar la interaccion entre el subsistema de re- 
cogida de datos y los instrumentos que recogen los datos meteoroldgicos. Utilice diagramas de secuen- 
cia para mostraresta interaccion. 

14.7 Identifique los objetos posibles en los siguientes sistemas y desarrolle un diseno orientado a objetos para 
ellos. Puede hacer suposiciones razonables acerca de los sistemas al derivar el diseho. 

• Un sistema para administrar las agendasy el tiempo de un grupo que pretende apoyar la programacion 
de reuniones y citas de un grupo de colaboradores. Cuando se da una cita que comprende a varias per- 
sonas, el sistema encuentra un hueco comun en cada una de las agendas y confirma la cita para esa 
hora. Si no existen huecos disponibles, interactua con los usuarios para arreglar sus agendas persona- 
les con el fin de hacer un hueco para la cita. 

• Una gasolinera va a operar completamente automatizada. Los conductores pasan sus tarjetas de credi- 
to por un lector situado en el surtidor; la tarjeta se verifica mediante una comunicacion con la compu- 
tation! de la compama de credito, y se establece un limite de gasolina. Despues el conductor reposta la 
cantidad de combustible deseado. Cuando se completa la entrega y se cuelga ta manguera de la bom- 
ba, se le aplica el cargo del coste de la gasolina suministrada a la tarjeta de credito del conductor. Se le 
devuelve la tarjeta de credito despues de aplicar el cargo. Si la tarjeta no es valida, esta es devuelta an- 
tes de suministrar la gasolina. 

IAS Redacte las definiciones precisas de las interfaces en Java o en C++ para los objetos definidos en el ejer- 
cicio 14.7. 

14.9 Dibuje un diagrama de secuencia que muestre las interacciones de los objetos en un sistema que maneja 
las agendas de un grupo cuando un grupo de personas tratan de concertar una cita. 

14.10 Dibuje un diagrama de estado que muestre los cambios de estado posibles en uno o mas objetos defini- 
dos en el Ejercicio 14.7. 



Diseno de software 
de tiempo real 



Objetivos 

Los objetivos de este capitulo son introducir las tecnicas usadas 
en el diseno de sistemas de tiempo real y describir algunas 
arquitecturas genericas de sistemas de tiempo real. Cuando haya 
leido este capitulo: 

• comprendera el concepto de sistema de tiempo real y por que 
los sistemas de tiempo real se implementan normalmente 
como un conjunto de procesos concurrentes; 

• habra sido introducido en el proceso de diseno de sistemas 
de tiempo real; 

• comprendera el papel que desempena un sistema operativo 
de tiempo real; 

• conocera las arquitecturas de procesos genericos para 
sistemas de monitorizacion y control y sistemas de 
adquisicion de datos. 

Contenidos 

15.1 Disefio del sistema 

15.2 Sistemas operativos de tiempo real 

15.3 Sistemas de monitorizacion y control 

15.4 Sistemas de adquisicion de datos 
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Las computadoras se utilizan para controlar una amplia variedad de sistemas que van desde 
maquinas domesticas sencillas hastaplantas enteras de fabricacion. Estas computadoras inter- 
actuan directamente con dispositivos hardware. El software de dichos sistemas es software de 
tiempo real embebido que debe reaccionar a eventos generados por el hardware y emitir se- 
nales de control como respuesta a estos eventos. Esta embebido en sistemas hardware mas 
grandes y debe responder, en tiempo real, a eventos del entorno del sistema. 

Los sistemas de tiempo real embebidos son diferentes de otros tipos de sistemas software. 
Su correcto funcionamiento depende de que el sistema responda a los eventos dentro de un 
corto intervalo de tiempo. Se puede definir un sistema de tiempo real como sigue: 

Un sistema de tiempo real es un sistema software cuyo correcto funcionamiento de- 
pende de tos resultados producidos por el mismoy del instante de tiempo en el que se 
producen estos resultados. Un sistema de tiempo real blando (soft) es un sistema cuyo 
funcionamiento se degrada silos resultados no se producen de acuerdo con los reque- 
rimientos temporales especificados. Un sistema de tiempo real duro (hard) es un siste- 
ma cuyo funcionamiento es incorrecto si los resultados nose producen de acuerdo con 
la especificacion temporal. 

Una respuesta a tiempo es un factor importante en todos los sistemas embebidos, pero, en 
algunos casos, no es necesaria una respuesta muy rapida. Por ejemplo, el sistema de bomba 
de insulina que se utiliza como ejemplo en varios capitulos de este libro es un sistema embe- 
bido. Sin embargo, aunque se necesita comprobar el nivel de glucosa a intervalos periodicos, 
no es necesario responder muy rapidamente a los eventos extemos. Por lo tanto, se utilizan 
ejemplos diferentes en este capitulo para ilustrar los fundamentos de diseno de los sistemas 
de tiempo real. 

Una forma de ver un sistema de tiempo real es como un sistema de estimulo/respuesta. 
Dado un determinado estimulo de entrada, el sistema debe producir la correspondiente sali- 
da. Se puede, por lo tanto, definir el comportamiento de un sistema de tiempo real haciendo 
una lista de los estimulos recibidos por el sistema, las respuestas asociadas y el tiempo en el 
que dichas respuestas deben producirse. 

Los estimulos pueden pertenecer a dos clases: 

1 . Estimulos periodicos. Ocurren a intervalos de tiempo predecibles. Por ejemplo, el sis- 
tema debe examinar un sensor cada 50 milisegundos y realizar una accion (respuesta) 
dependiendo del valor de ese sensor (estimulo). 

2. Estimulos aperiodicos. Ocurren de forma irregular. Normalmente son provocados uti- 
lizando el mecanismo de interrupciones de la computadora. Un ejemplo de dicho es- 
timulo podria ser una interrupcion para indicar que una transferencia de E/S se ha com- 
pletado y que los datos estan disponibles en un bufer. 

Los estimulos periodicos en un sistema de tiempo real son generados normalmente por sen- 
sores asociados al sistema. Estos proporcionan informacion sobre el estado del entorno del sis- 
tema. Las respuestas son dirigidas a un conjunto de actuadores que controlan algun equipo, 
como una bomba, que influye en el entorno del sistema. Los estimulos aperiodicos pueden ge- 
nerarse por actuadores o por sensores. A menudo indican alguna condicion excepcional, como 
un fallo en el hardware, que debe ser manejado por el sistema. Este modelo sensor-sistema- 
actuador de un sistema de tiempo real embebido se ilustra en la Figura 15.1. 

Un sistema de tiempo real tiene que responder a estimulos que ocurren en diferentes ins- 
tantes de tiempo. Por lo tanto, se tiene que organizar su arquitectura para que, tan pronto como 
se reciba un estimulo, el control sea transferido al manejador adecuado. Esto no es practico 
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Figura 15.1 
Modelo general de 
un sistema de 
tiempo real. 




enprogramas secuenciales. Por consiguiente, los sistemas de tiempo real se disenan como un 
conjunto de procesos concurrentes que cooperan entre si. Con el objeto de soportar la gestion 
de estos procesos, la plataforma de ejecucion para la mayoria de los sistemas de tiempo real 
incluye un sistema operativo de tiempo real. Las facilidades que proporciona este sistema ope- 
rativo son accedidas a traves del sistema de soporte en tiempo de ejecucion (run-time system) 
para el lenguaje de programacion de tiempo real utilizado. 

La generalidad de este modelo estimulo-respuesta de un sistema de tiempo real con- 
duce a un modelo arquitectonico generico abstracto en el que hay tres tipos de procesos. 
Para cada tipo de sensor, hay un proceso de gestion del sensor; los procesos computacio- 
nales calculan la respuesta requerida para el estimulo recibido por el sistema; los procesos 
de control de actuadores controlan el funcionamiento del actuador. Este modelo permite 
recoger rapidamente los datos desde el sensor (antes de que la siguiente entrada este dis- 
ponible) y permite que su procesamiento y la respuesta asociada al actuador se realicen mas 
tarde. 

La arquitectura generica puede instanciarse a varias arquitecturas de aplicaciones diferen- 
tes que amplian el conjunto de arquitecturas estudiadas en el Capitulo 13. Las arquitecturas 
de aplicaciones de tiempo real son instancias de la arquitectura conducida por eventos en la 
cual el estimulo, directao indirectamente, provoca lageneracion de eventos. En este capitu- 
lo, se introducen dos arquitecturas de aplicaciones mas: la arquitectura para sistemas de mo- 
nitorizacion y control (en la Seccion 15.3), y la arquitectura para sistemas de adquisicion de 
datos. 

Los lenguajes de programacion desarrollados para sistemas de tiempo real tienen que in- 
cluir facilidades para acceder al hardware del sistema, y deberia serposible predecir la dura- 
cion de operaciones particulares realizadas en estos lenguajes. Los sistemas de tiempo real du- 
ros todavia se programan algunas veces en ensamblador para que puedan cumplirse los 
estrechos plazos de tiempo (deadline). Los lenguajes a nivel de sistemas, como C, que per- 
miten generarcodigo eficiente tambien se utilizan en general. 

La ventaja de utilizar un lenguaje de programacion de sistemas de bajo nivel como C es 
que permite el desarrollo de programas muy eficientes. Sin embargo, estos lenguajes no in- 
cluyen construcciones para soportar la concurrencia o la gestion de recursos compartidos. Es- 
tas se implementan a traves de llamadas al sistema operativo de tiempo real que no pueden 
ser comprobadas por el compilador, de forma que los errores de programacion son mas pro- 
bables. Los programas son tambien a menudo mas dificiles de comprender debido a que las 
caracteristicas de tiempo real no estan explicitas en el programa. 
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Desde hace pocos anos, se ha venido realizando un amplio trabajo a fin de extender Java 
para el desarrollo de sistemas de tiempo real (Nilsen, 1998; Higuera-Toledano e Issamy, 
2000; Hardin et ah, 2002). Este trabajo implica la modificacion del lenguaje para tratar los 
principales problemas de tiempo real: 

1. No es posible especificar el instante de tiempo en el que los hilos se deberian ejecu- 
tar. 

2. La recoleccion de basura es incontrolable: puede empezar en cualquier momento. Por 
lo tanto, el comportamiento temporal de los hilos es impredecible. 

3. No es posible descubrir los tamanos de las colas asociadas con recursos compartidos. 

4. La implementacion de la Maquina Virtual de Java variade una computadora a otra, de 
forma que el mismo programa puede tener diferentes comportamientos temporales. 

5. El lenguaje no permite un analisis detallado de la memoria o del procesador en tiem- 
po de ejecucion. 

6. No hay una forma estandar de acceder al hardware del sistema. 

Las versiones de tiempo real de Java, como J 2 ME de Sun (Java 2 Micro Edition), estanac- 
tualmente disponibles. Varios vendedores suministran implementaciones de la Maquina Vir- 
tual de Java adaptada al desarrollo de sistemas de tiempo real. Estos desarrollos implican que 
Java se usaracada vez mas como lenguaje de programacion en tiempo real. 

15.1 Diseno del sistema 

Tal y como se indico en el Capitulo 2, parte del proceso de diseno implica decidirque capa- 
cidades del sistema tienen que implementarse en software y cuales en hardware. Para muchos 
sistemas de tiempo real embebidos en productos de consumo, como los sistemas en aparalos 
telefonicos, los costes y la potencia de consumo del hardware, son criticos. Se pueden utili- 
zar procesadores especificos disenados para soportar sistemas embebidos y, para algunos sis- 
temas, tiene que disenarse y construirse hardware de proposito especifico. 

Esto significa que un proceso de diseno desde arriba hacia abajo — en el que el diseno co- 
mienza con un modelo abstracto que se va descomponiendo y desarrollando en una serie de 
etapas — no es practico para la mayoria de los sistemas de tiempo real. Las decisiones de bajo 
nivel sobre el hardware, el software de soporte y las cuestiones temporales sobre el sistema 
deben considerarse en etapas tempranas del proceso de desarrollo. Esto limita la flexibilidad 
de los disenadores del sistema y puede implicar que se requieran funcionalidades software 
adicionales, como la gestion de labateriay del suministro electrico. 

Los eventos (estimulos) deberian serelementos centrales del proceso de diseno de software 
de tiempo real en lugar de los objetos o funciones. Hay varias etapas intercaladas en este pro- 
ceso de diseno: 

1. Identificar los estimulos que el sistema debe procesar y las respuestas asociadas. 

2. Para cada estimulo y respuesta asociada, identificar las restricciones temporales que 
se aplican tanto al procesamiento del estimulo como al de la respuesta. 

3. Elegir una plataforma de ejecucion para el sistema: el hardware y el sistema operati- 
vo de tiempo real que se va a utilizar. Entre los factores que influyen en esla eleccion 
se encuentran las restricciones temporales del sistema, las limitaciones de energia dis- 
ponible, la experiencia del grupo de desarrollo y el coste de la maquina en la que se 
va a ejecutar el sistema entregado. 
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4. Incorporar el procesamiento de estimulos y respuestas a varios procesos concurrentes. 
Una buena regla en el diseno de sistemas de tiempo real es asociar un proceso con cada 
tipo de estlmulo y respuesta tal y como se muestra en la Figura 15.2. 

5. Para cada estlmulo y respuesta, disefiar algoritmos para llevar a cabo los calculos re- 
queridos. Los disenos de los algoritmos tienen que desarrollarse a menudo relativa- 
mente pronto en el proceso de diseno para proporcionar una indicacion de la cantidad 
de procesamiento requerido y del tiempo necesario para completar dicho procesa- 
miento. 

6. Disefiar un sistema de planificacion de los procesos que asegure que dichos procesos 
comienzan a tiempo para cumplir sus plazos de ejecucion. 

El orden de estas actividades en el proceso depende del tipo de sistema que se este de- 
sarrollando y de los requerimientos de su proceso y plataforma. En algunos casos, se puede 
seguir una aproximacion completamente abstracta en la que se empieza con los estimulos y 
el procesamiento asociado y se decide mas tarde en el proceso el hardware y las plataformas 
de ejecucion. En otros casos, la eleccion del hardware y el sistema operativo se realiza antes 
de que comience el diseno del software, y se tiene que orientar el diseno segun las capacida- 
des del hardware. 

Los procesos en un sistema de tiempo real tienen que coordinarse. Los mecanismos de 
coordinacion de procesos aseguran la exclusion mutua de recursos compartidos. Cuando un 
proceso modifica un recurso compartido, al resto de los procesos no se les deberla permitir 
cambiar ese recurso. Los mecanismos para asegurar la exclusion mutua comprenden semafo- 
ros (Dijkstra, 1968), monitores (Hoare, 1974) y regiones criticas (Brinch-Hansen, 1973). Es- 
tos mecanismos se describen en la mayorla de los textos sobre sistemas operativos (Tanen- 
baum, 2001; Silberschatz, el al, 2002). 

Una vez que se ha elegido la plataforma de ejecucion para el sistema, se ha disenado una 
arquitectura para el proceso y se ha decidido una polltica de planificacion (scheduling), pue- 
de necesitarse comprobar que el sistema satisface sus requerimientos temporales. Se puede 
hacer esto mediante el analisis estatico del sistema utilizando conocimientos sobre el com- 
portamiento temporal de los componentes, o tambien mediante simulacion. Este analisis pue- 
de revelar que el sistema no funcionara de forma adecuada. Entonces, la arquitectura del pro- 
ceso, la polltica de planificacion del procesador, la plataforma de ejecucion o todos ellos 
pueden tener que ser redisefiados para mejorar el rendimiento del sistema. 

El analisis temporal para sistemas de tiempo real es diflcil. Debido a que los estimulos ape- 
riodicos son impredecibles, los disenadores tienen que hacer suposiciones sobre laprobabili- 
dad de ocurrencia de estos estimulos (y por lo tanto del servicio requerido) en un instante de 
tiempo concreto. Estas suposiciones pueden ser incorrectas, y el rendimiento del sistema des- 
pues de la entrega puede no ser el adecuado. El libro de Cooling (Cooling, 2003) describe las 
tecnicas para el analisis de rendimiento de sistemas de tiempo real. 
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Debido a que los sistemas de tiempo real deben satisfacer sus restricciones temporales, es 
posible que no se pueda usar el desarrollo orientado a objetos para sistemas de tiempo real 
duros. El desarrollo orientado a objetos implica la ocultacion de representaciones de datos y 
el acceso a los valores de los atributos a traves de operaciones definidas en el objeto. Esto sig- 
nifica que hay una sobrecarga significativa que afecta al rendimiento en sistemas orientados 
a objetos, debido a que se necesita codigo extra para acceder a los atributos y para manejar 
las llamadas a las operaciones. La consecuente perdida de rendimiento puede hacer imposi- 
ble el satisfacer los plazos temporales de tiempo real. 

Las restricciones temporales u otros requerimientos pueden implicar a veces que es mejor 
implementar algunas funciones del sistema, tales como el procesamiento de la serial, en hard- 
ware en vez de en software. Los componentes hardware consiguen un rendimiento mucho me- 
jor que su equivalente software. Pueden identificarse los cuellos de botella en el procesa- 
miento de sistemas y ser sustituidos por hardware, con lo que se evitan optimizaciones del 
software caras. 

15.1.1 Modelado de sistemas de tiempo real 

Los sistemas de tiempo real deben responder a eventos que tienen lugar a intervalos irregula- 
res. Estos eventos (o estimulos) a menudo hacen que el sistema cambie a un estado diferen- 
te. Por esta razon, el modelado de maquina de estados, descrito en el Capitulo 8, se utiliza a 
menudo para modelar sistemas de tiempo real. 

Los modelos de maquina de estados son una buena aproximacion independiente del len- 
guaje de representar el diseno de un sistema de tiempo real y, por lo tanto, son una parte in- 
tegral de los metodos de diseno de sistemas de tiempo real (Gomaa, 1993). U M L soporta el 
desarrollo de modelos de estados basados en diagramas de estado (Harel, 1987; Harel, 1988). 
Los diagramas de estado estructuran los modelos de estados para que los grupos de estados 
puedan considerarse como una unica entidad. Douglass analiza el uso de U M L en el desarro- 
llo de sistemas de tiempo real (Douglass, 1999). 

Un modelo de estados de un sistema supone que, en cualquier momento, el sistema esta en 
uno de varios estados posibles. Cuando se recibe un estimulo, este puede produciruna tran- 
sicion a un estado diferente. Por ejemplo, un sistema que controla una valvula puede pasar 
desde un estado « Valvula abierta» a un estado « Valvula cerrada» cuando se recibe una orden 
(el estimulo) del operador. 

Ya se ha ilustrado esta aproximacion para el modelado de sistemas en el Capitulo 8 utili- 
zando el modelo de un sencillo horno microondas. La Figura 15.3 es otro ejemplo de un mo- 
delo de maquina de estados que muestra el funcionamiento de un sistema software de sumi- 
nistro de combustible en una bomba de petroleo (gas). Los rectangulos redondeados 
representan estados del sistema, y las flechas representan estimulos que fuerzan una transi- 
cion de un estado a otro. Los nombres elegidos en el diagrama de maquina de estados son des- 
criptivos y la informacion asociada indica las acciones realizadas por los actuadores del sis- 
tema o la informacion que es visualizada. 

El sistema de suministro de combustible se disena para permitir un funcionamiento auto- 
matico. El comprador inserta una tarjeta de credito en un lector de tarjetas incluido en la bom- 
ba. Esto provoca una transicion a un estado Leyendo en donde los detalles de la tarjeta son le- 
idos y se le solicitaal comprador que retire la tarjeta. El sistema se mueve al estado Validando 
en donde la tarjeta es validada. Si la tarjeta es valida, el sistema inicializa la bomba y, cuando 
la manguera del combustible es retirada de su soporte, esta lista para suministrar el combusti- 
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Figura 15.3 Modelo de maquina de estados de una bomba de petroleo (gas). 



ble. Activando el gatillo de la boquilla de la manguera se bombea el combustible; este se de- 
tiene cuando se suelta el gatillo (por simplificar, no se ha tenido en cuenta el interruptor de pre- 
sion disenado para detenerun posible derrame del combustible). Cuando se ha completado el 
suministro de combustible y el comprador ha vuelto a colocar la manguera en su soporte, el 
sistema pasa al estado Pagando en donde se realiza un cargo en la cuenta del cliente. 



15.2 Sistemas operativos de tiempo real 

Todos los sistemas de tiempo real, incluso hasta los sistemas embebidos mas sencillos, tra- 
bajan hoy en dia conjuntamente con un sistema operativo de tiempo real (RTOS). Un sistema 
operativo de tiempo real gestiona los procesos y asignacion de recursos en un sistema de tiem- 
po real. Lanza y detiene los procesos para que los estimulos puedan ser manejados y asigna 
memoria y recursos del procesador. Hay muchos productos RTOS disponibles, desde siste- 
mas sencillos muy pequenos para dispositivos de consumo, hasta sistemas complejos para te- 
lefonos y dispositivos moviles, y sistemas operativos especificamente disenados para control 
de procesos y telecomunicaciones. 

Los componentes de un RTOS (Figura 15.4) dependen del tamano y complejidad del sis- 
tema de tiempo real que se este desarrollando. Normalmente, exceptuando los sistemas mas 
sencillos, todos incluyen: 
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1. Un reloj de tiempo real. Proporciona informacion para planificar los procesos de for- 
ma periodica. 

2. Un manejador de interrupciones. Gestiona las solicitudes aperiodicas de los servi- 
cios. 

3 . Un planificador. Este componente se encarga de examinar los procesos que pueden ser 
ejecutados y elegir uno de ellos para su ejecucion. 

4. Un gestor de recursos. Dado un proceso que es planificado para ejecucion, el gestor 
de recursos asigna la memoria adecuada y los recursos del procesador. 

5. Un despachador. Este componente tiene la funcion de iniciar la ejecucion de un pro- 
ceso. 

Los sistemas operativos de tiempo real para sistemas grandes, tales como control de pro- 
cesos o sistemas de telecomunicaciones, pueden tener facilidades adicionales, tales como ges- 

15 2 1 iSfSVH dh n tK n |iii 1 iffite'^j^' SC0 y g est io n de fallos, que detectan e informan de fallos del sis- 
tema y un gestor de configuraciones que soporta la reconfiguracion dinamica de aplicaciones 

fey^ m iernas a a , e tiempo real tienen que manejar eventos externos rapidamente y, en algunos 
casos, satisfacer plazos de tiempo para el procesamiento de estos eventos. Esto significa que 
los procesos de manejo de eventos deben serplanificados a tiempo para su ejecucion y asi de- 
tectar el evento, y se deben asignar suficientes recursos del procesador para satisfacer su pia- 
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zo de tiempo. El gestorde procesos en un RTOS es responsable de elegir los procesospara su 
ejecucion, asignarel procesadory recursos de memoria, e iniciar ydetener la ejecucion deun 
proceso sobre un procesador. 

El gestor de procesos tiene que gestionar procesos con diferentes prioridades. Para algu- 
nos estimulos, como los asociados con ciertos eventos excepcionales, es esencial que su pro- 
cesamiento sea completado dentro de los Hmites de tiempo especificados. Otros procesos pue- 
den retrasarse de forma segura si un proceso mas critico requiere el servicio. Como 
consecuencia, los RTOS tienen que ser capaces de gestionar al menos dos niveles de priori- 
dad para los procesos del sistema: 

1. Nivel de interruption. Es el nivel de prioridad mas alto. Se asigna a procesos que ne- 
cesitan una respuesta muy rapida. Uno de estos procesos sera el proceso del reloj de 
tiempo real. 

2. Nivel de reloj. Este nivel de prioridad se asigna a los procesos periodicos. 

Puede haber un nivel mas de prioridad asignado a los procesos que se ejecutan en un se- 
gundo piano (tales como un proceso de autocomprobacion) que no tienen un plazo limite de 
terminacion. Estos procesos son planificados para su ejecucion cuando el procesador este 
ocioso. 

Dentro de cada uno de estos niveles de prioridad, se pueden asignar diferentes prioridades 
a distintos tipos de procesos. Por ejemplo, pueden existir varias lineas de interrupcion. Una 
interrupcion de un dispositivo muy rapido puede interrumpir el procesamiento de una inte- 
rrupcion de un dispositivo mas lento para evitar la perdida de informacion. La asignacion de 
prioridades de procesos para que todos ellos sean atendidos a tiempo requiere normalmente 
un extenso analisis y simulacion. 

Los procesos periodicos son procesos que deben ejecutarse a intervalos de tiempo prede- 
finidos para la adquisicion de datos y el control de los actuadores. En la mayoria de los siste- 
mas de tiempo real, habra varios tipos de procesos periodicos. Estos tendran diferentes pe- 
riodos (el tiempo transcurrido entre ejecuciones del proceso), tiempos de ejecucion y plazos 
de tiempo (el tiempo en el cual se debe completar el procesamiento). Utilizando los requeri- 
mientos temporales especificados en el programa de la aplicacion, el RTOS ordena la ejecu- 
cion de los procesos periodicos para que todos ellos puedan cumplir sus plazos de tiempo. 

Las acciones llevadas a cabo por el sistema operativo para la gestion de procesos periodi- 
cos se muestran en la Figura 15.5. El planificador examina la lista de procesos periodicos y 
selecciona un proceso para su ejecucion. Laelecciondependede la prioridad de los procesos, 
de los periodos de los procesos, de los tiempos de ejecucion esperados y de los plazos de tiem- 
po de los procesos listos para ejecucion. Algunas veces, dos procesos con diferentes plazos 
de tiempo deberian ejecutarse en el mismo tic del reloj . En tal situacion, un proceso debe re- 
trasarse de forma que su plazo de tiempo todavia pueda cumplirse. 

Los procesos que tienen que responder a eventos asincronos son normalmente conducidos 
por interrupciones. El mecanismo de interrupciones de la computadora hace que el control se 
transfiera a unaposicion de memoria predeterminada. Esta posicion contiene una instruccion 
para saltar a una rutina de servicio de interrupciones sencilla y mas rapida. La rutina de ser- 
vicio de interrupciones primero inhabilita las interrupciones para evitar ser interrumpida. 
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Seguidamente, encuentra la causa de la interrupcion e inicia, con Laprioridad mas alta, unpro- 
ceso que maneja los estimulos que provocan la interrupcion. En algunos sistemas de adquisi- 
cion de datos de alta velocidad, el manejador de interrupciones guarda los datos marcados por 
la interrupcion para su procesamiento posterior. A continuacion, las interrupciones se habili- 
tan de nuevo y el control se devuelve al sistema operative 

En cualquier momento, pueden existirvarios procesos, condiferentesprioridades, quepo- 
drian ejecutarse. El planificador del proceso implementa las politicas de planificacion del sis- 
tema que determinan el orden de la ejecucion de los procesos. Hay dos estrategias funda- 
mentals de planificacion: 

1 . Planificador sin reemplazo. Una vez que un proceso ha sido planificado para su eje- 
cucion, se ejecuta hasta el final o hasta que se bloquee por alguna razon, tal como la 
espera de una entrada. Esto puede causar problemas cuando existen procesos con di- 
ferentes prioridades y un proceso con una prioridad mas alta tiene que esperar a que 
un proceso de menor prioridad termine. 

2. Planificacion con reemplazo. La ejecucion de un proceso se puede detener si un pro- 
ceso de prioridad mas alta requiere el uso del procesador. El proceso de prioridad mas 
alta reemplaza la ejecucion del proceso de prioridad mas bajay se le asigna el proce- 
sador. 

Dentro de estas estrategias, se han desarrollado diferentesalgoritmosde planificacion. Es- 
tos comprenden la planificacion denominada round-robin, en donde cada proceso se ejecuta 
porturnos, la planificacion de frecuenciamonotona (rate monotonia), en donde se le da prio- 
ridad al proceso con el periodo mas corto, y la estrategia de planificacion consistente en eje- 
cutarprimero el proceso con elplazo de tiempo mas corto (Burns y Wellings, 2001). 

La informacion sobre los procesos a ejecutar se envia al gestor de recursos. Este asigna me- 
moria y, en un sistema multiprocesador, un procesador a este proceso. Despues el proceso se 
situa en la lista de procesos preparados, que es una lista de procesos listos para su ej ecucion. 
Cuando un procesador termina de ejecutar un proceso y vuelve a estar disponible, se invoca 
al despachador. Este examina la lista de preparados para encontrarun proceso que pueda eje- 
cutarse en el procesador disponible e inicia su ejecucion. 

15.3 Sistemas de monitonzacion y control 

Los sistemas de monitorizacion y control son una clase importante de sistemas de tiempo real. 
Estos comprueban los sensores que proporcionan informacion sobre el entorno del sistema y 
llevan a cabo acciones dependiendo de la lectura del sensor. Los sistemas de monitorizacion 
realizan una accion cuando se detecta algun valor excepcional del sensor. Los sistemas de con- 
trol controlan continuamente los actuadores hardware dependiendo del valor de los sensores 
asociados. 

Las caracteristicas de los sistemas de monitorizacion y control se muestran en la Figu- 
ra 15.6. Cada tipo de sensor que se esta monitorizando tiene su propio proceso de monitori- 
zacion, asi como cada tipo de actuadorque se esta controlando. Un proceso de monitoriza- 
cion recopila e integra los datos antes de enviarlos a un proceso de control, el cual toma de- 
cisiones basadas en estos datos y envia los comandos de control adecuados a los procesos de 
control del equipo. En sistemas simples, las responsabilidades de monitorizacion y control 
pueden integrarse en un unico proceso. Aqui tambien se han mostrado otros dos procesos que 
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Figura 15.6 
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pueden incluirse en sistemas de monitorizacion y control. Estos son: un proceso de pruebas 
que puede ejecutar programas de test del hardware y un proceso de panel de control que ges- 
tiona los paneles de control del sistema o la consola del operador. 

Para ilustrar el diseno de los sistemas de monitorizacion y control, seutilizaunejemplo de 
un sistema de alarma antirrobo que podria instalarse en un edificio de oficinas: 

Se tiene que implementar un sistema software para controlar un sistema de alarma anti- 
robo para su instalacion en edificios comerciales. Este utiliza varios tipos de sensores, que 
comprenden detectores de movimiento en estancias individuales, sensores en las ventanas 
de la planta baja que detectan cuando se ha abierto o roto la ventana, y sensores en las puer- 
tas de los pasillos que detectan la apertura de estas. El sistema se compone de 50 sensores 
en las ventanas, 30 sensores en las puertas y 200 detectores de movimiento. 

Cuando un sensor detecta la presencia de un intruso, el sistema automaticamente rea- 
liza una llamada a la policia local y, utilizando un sintetizador de voz, informa de la lo- 
calizacion de la alarma. Enciende las luces en las estancias alrededor del sensor activo y 
activa una alarma sonora. El sistema de sensores normalmente utiliza el suministro elec- 
trico general, pero ademas esta equipado con una bateria de apoyo. La perdida de ener- 
gia se detecta utilizando un monitor de circuito de energia independiente que monitoriza 
los principales voltajes. Este interrumpe el sistema de alarma cuando se detecta una cai- 
da de voltaje. 

Este sistema es un sistema de tiempo real «blando» que no tiene requerimientos tempora- 
les estrictos. Los sensores no necesitan detectar eventos a altas velocidades; solamente nece- 
sitan ser consultados dos veces por segundo. Para hacer que el ejemplo sea mas facil de en- 
tender, se ha simplificado el diseno dejando de lado los procesos de pruebay visualizacion. 

El proceso de diseno sigue los pasos indicados en la Seccion 15.1, por lo que se comien- 
za identificando los estimulos aperiodicos que recibe el sistema y sus respuestas asociadas. 
Debido a las simplificaciones en el diseno propuesto, pueden pasarse por alto los estimulos 
generados por los procedimientos de prueba del sistema y las senales extemas para desacti- 
varlo en caso de un evento de falsa alarma. Esto significa que solamente hay que procesar dos 
tipos de estimulos: 

1. Fallo en el suministro electrico. Este se genera por el monitordel circuito. Larespuesta 
requerida es activar el circuito de la bateria de apoyo enviando senales a un interrup- 
ter electronico de la bateria. 
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2. Alarma contra intrusos. Este es un estimulo generado por uno de los sensores del sis- 
tema. La respuesta a este estimulo es calcular el numero de la estancia del sensor ac- 
tivo, realizar una llamada a la policia, iniciar el sintetizador de voz para efectuar la 11a- 
mada, y activar la alarma sonora para intrusos y las luces del edificio en el area. 

El siguiente paso en el proceso de diseno es considerar las restricciones temporales aso- 
ciadas a cada estimulo y su correspondiente respuesta. Estas restricciones temporales se mues- 
tran en la Figura 15.7. Normalmente, se deberian listar las restricciones temporales para cada 
tipo de sensor de forma independiente, incluso cuando, como ocurre en este caso, todas sean 
las mismas. Gestionandolas de forma independiente, facilita futuros cambios y resulta mas 
sencillo calcular el numero de veces que el proceso de control tiene que ejecutarse cada se- 
gundo. 

La asignacion de las funciones del sistema a procesos concurrentes es la siguiente etapa de 
diseno. Hay tres tipos de sensores que deben consultarse de forma periodica, cada uno conun 
proceso asociado. Existe un sistema conducido por interrupciones para manejar los fallos en 
el suministro electrico y el cambio a la bateria de apoyo, un sistema de comunicaciones, un 
sintetizador de voz, un sistema de alarma sonora y un sistema de encendido de luces para en- 
cender las luces alrededor del sensor. Un proceso independiente controla cada uno de estos 
sistemas. Esto conduce a la arquitectura del sistema mostrada en la Figura 15.8. 

En la Figura 15.8, las flechas etiquetadas unen procesos, indicando los flujos de datos en- 
tre ellos, mientras que la etiqueta indica el tipo de flujo de datos. No todos los procesos reci- 
ben datos de otros procesos. Por ejemplo, el proceso responsable de gestionar un fallo en el 
suministro electrico no necesita de ningun proceso del sistema. 

La linea asociada con cada proceso sobre su extremo superior izquierdo se utiliza para in- 
dicarcomo se controla el proceso. Las lineas sobre un proceso periodico son lineas continuas 
cuya etiqueta indica el numero minimo de veces que un proceso deberia ejecutarse por se- 



Estimulo/Respuesta Requerimientos temporales 



Figura 15.7 
Requerimientos 
temporales del 
estimulo/respuesta. 



trrterruptor de fallos en 
el suministro electrico 

Alarma de puerta 



Alarma de ventana 
Detector de mownwnto 
Alarma sonora 
Interrupter de luces 
Comunkadoms 
Sintetizador de voz 



El cambio al suministro electrico de apoyo debe completarse en 
un ptazo manmo de 50 ms. 

Cada alarma de puerta deberia ser consuttada dos veces por 
segundo. 

Cada alarma de ventana deberia ser consuttada dos veces por 
segundo. 

Cada detector de rrwvirmento deberia ser consultado dos veces 
por segundo. 

La alarma sonora deberia ser aebvada an medio segundo 
despues de que una alarma sea aebvada por un sensor 

las luces deberian ser encendides en medio segundo a partir de 
que una alarma sea activada por un sensor. 

La llamada « la poHda deberia comenzar a los dos segundos de 
que una alarma sea actmda por un sensor. 

Un mensaje stntetizado deberia estar dbponMe a los cuatro 
segundos de que una alarma sea actmda por un sensor. 
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gundo. Los procesos aperiodicos tienen Hneas discontinuas sobre su extremo superior iz- 
quierdo, etiquetadas con el evento que hace que el proceso se planifique. 

El numero de sensores que tienen que ser consultados y los requerimientos temporales 
del sistema se utilizan para calcular la periodicidad con la que cada proceso tiene que ser 
planificado. Por ejemplo, hay 30 sensores de puertas que deben ser comprobados dos veces por 
segundo. Esto significa que el proceso asociado al sensor de la puerta debe ejecutarse 
60 veces por segundo (60 Hz). El proceso del detector de movimiento debe ejecutarse 
400 veces por segundo debido a que hay 200 sensores de movimiento en el sistema. La infor- 
macionde control sobre los procesos del actuador (por ejemplo, el controladorde la alarma so- 
nora, el controladorde las luces, etc.) indica que han sido activados por una orden explicita del 
proceso Sistema de alarma o por una Interrupcion de fallo de suministro electrico. 

Estos pueden implementarse en Java utilizando hilos de ejecucion. La Figura 15.9 mues- 
tra el codigo Java que implemenla el proceso BuildingMonitor, que realiza una consulta a los 
sensores del sistema. Si estos detectan un intruso, el software activa el sistema de alarma aso- 
ciado. Aqui se utiliza Java estandary se supone que los requerimientos temporales (incluidos 
como comentarios) pueden cumplirse. Tal y como se indico anteriormente, el lenguaje Java 
en su forma estandar no incluye facilidades parapermitir la especificacion de la frecuencia de 
ejecucion de los hilos. 

Una vez que ha sido definida la arquitectura de los procesos del sistema, deberian disenarse 
los algoritmos para el procesamiento de los estimulos y la generacion de respuestas. Tal y 
como se explico en la Seccion 15.1, esta etapa de diseno detallado es necesaria al principio 
del proceso de diseno para asegurar que el sistema pueda cumplir sus restricciones de tiem- 
po especificadas. Si los algoritmos asociados son complejos, se pueden requerir cambios en 
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Figura 15.8 
Arquitectura de 
procesos del sistema 
de alarma antirrobo. 



Sistema de alarma 



Numero de habitacibn 
Sistema de alarma 

i 



Sistema de alarma 
if Numero de habitacion jf 



C Proceso de la "\ /*~ ^roceso de controTv \ /* Proceso del \ 
alarma audible J I de las luces J ^\ sintetizador de voz J 



322 CAPITULO 15 • Disefio de software de tiempo real 



las restricciones de tiempo. Sin embargo, a menos que se requiera el procesamiento de sefia- 
les, los algoritmos de sistemas de tiempo real son a menudo bastante sencillos. Estos sola- 
mente pueden requerir la comprobacion de una posicion de memoria, realizar algunos calcu- 
los sencillos o emitir una senal. Como puede verse en la Figura 15.9, el procesamiento 
requerido en el sistema de alarma antirrobo sigue este sencillo modelo. 



// ver h^^Awvw joftware-engin.com/ para completar el codtgo Java de este ejempte 

dess BuAdingMonitor extends Thread { 

BuiMngSeraor win, dow; move ; 

Siren siren <■> new Siren 0 ; 

Lights fights -new Lights 0 ; 

Synthesizer synthesiiet »» new Synthesizer 0 ; 

DoofSemors doors * new DoorSensors (30) ; 

WmdowSensors windows - new WindowSensofs (50) ; 

MowementSensors movements - new MovementSensors (200) ; 

PowerMonitOf pm ■« new PowefMonitof 0 ; 

BuMngMorutorO 

{ 

// initiafaa todos los sensores e mida los pracesos 
sireostart 0 ; lightsjtart 0 ; 
synthesizer.sta(t 0 ; windowsjtart 0 ; 
dooRhStart 0 ; movements^tsrt 0 ; pmstart 0 ; 



Figura 15.9 

Implementacidn Java 
del proceso 
Build ingMo nitor. 



(pubic void run 0 

H 

mt room - 0 ; 
while (true) 



{ 



// consufca kts sensores de mavimiento al menos dos veces por segundo (400 Hz) 
move - rnovernerrts-gelVal 0 ; 

// consufca los sensores de las ventanas ai menos dos veces/segundo (100 Hz) 
win^window&getVal 0 ; 

// consufca los sensores de las puertas al menos dos veces por segundo (GO Hz) 
door-doottgetValO; 

if (rmwcvscnsorVal 1 1 doouensorVsl — 1 1 wirusensorVal — l) 



{ 



// un sensor ha detectado un irttruso 
f (rnomsensortAji — 1) room » mov&room ; 
if (doorsensorVfel — 1) room • dooMoom ; 
if (wirisensorVal — 1 ) room - wiaroom ; 



HghRon (room) ; swerbon 0 ; fynthesizerjon (room) ; 
break; 

> 

} 

fegrttLshutdown 0 ; sirenjhutdown 0 ; syrtdiesizer^lMitdown 0 
windowsjhutdown 0 ; doorsjhutdown 0 mowementsjlwidown Q ; 



)//mn 
) //BufldrngMonitof 
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El paso final en el proceso de diseno es el diseno de un sistema de planificacion que ase- 
gure que un proceso siempre sera planificado para cumplir con sus plazos de tiempo. En este 
ejemplo, los plazos de tiempo no son ajustados. Las prioridades de los procesos deberian or- 
ganizarse para que todos los procesos que consultan sensores tengan la misma prioridad. El 
proceso para manejar un fallo en el suministro electricodeberiaserun proceso denivelde in- 
terrupcion con una prioridad mas alta. La prioridad de los procesos que gestiona el sistema 
de alarma deberia ser la misma que la de los procesos de los sensores. 

El sistema de alarma antirrobo es un sistema de monitorizac ion en vez de un sistema de 
control, puesto que no incluye actuadores que se vean directamente afectados por los valores 
del sensor. Un ejemplo de un sistema de control podria serun sistema de control de la cale- 
faccion de un edificio. Este sistema monitoriza los sensores de temperatura en diferentes es- 
tancias del edificio y apaga y enciende una unidad de calefaccion dependiendo de la tempe- 
ratura actual y de la temperatura fijada en el termostato de dicha estancia. El termostato 
tambiencontrola la activacion del generadorde calordel sistema. 

La arquitectura de los procesos de este sistema se muestra en la Figura 15.10. Esta claro 
que su forma general es similar al sistema de alarma antirrobo. Se deja al lector el desarrollo 
del diseno mas detallado de este sistema. 



15.4 Sistemas de adquisicion de datos 

Los sistemas de adquisicion de datos recogen datos de sensores para su posterior procesa- 
miento y analisis. Estos sistemas se utilizan en circunstancias en las que los sensores han 
recogido grandes cantidades de datos del entorno del sistema y no es necesario procesar los 
datos recopilados en tiempo real. Los sistemas de adquisicion de datos se usan normalmente 
en experimentos cientificos y sistemas de control de procesos en los que los procesos fisicos, 
tales como una reaccion quimica, ocurren muy rapidamente. 

En los sistemas de adquisicion de datos, los sensores pueden estar generando datos muy 
rapidamente, y el problema principal es asegurar que una lectura del sensor es recogida antes 
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de que cambie el valor del sensor. Esto da lugar a una arquitectura generica tal y como se 
muestra en la Figura 15.11. La caracteristica fundamental de la arquitectura de los sistemas 
de adquisicion de datos es que cada grupo de sensores tiene tres procesos asociados: el pro- 
ceso del sensor que interactua con el sensor y convierte datos analogicos a valores digitales 
si es necesario, un proceso bufer, y un proceso que consume los datos y realiza un procesa- 
miento adicional. 

Por supuesto, los sensores pueden ser de diferentes tipos, y el numero de sensores de un 
grupo depende de la velocidad a la que lleguen los datos desde el entorno. En la Figura 15.1 1 
se muestran dos grupos de sensores, Sl-s3 y s4-s6. Tambien se muestra, en la parte de la de- 
recha, un proceso adicional que visualiza los datos del sensor. La mayoria de los sistemas de 
adquisicion de datos incluyen procesos de visualizacion e informes que reiinen los datos re- 
cogidos y realizan un procesamiento adicional. 

Como ejemplo de un sistema de adquisicion de datos, considere el modelo de sistema mos- 
trado en la Figura 15.12. Este representa un sistema que recoge datos desde sensores que mo- 
nitorizan el flujo de neutrones en un reactor nuclear. Los datos del sensor se colocan en un 
bufer a partir del cual se extraen y procesan, y el nivel promedio del flujo se visualiza en una 
pantalla del operador. 

Cada sensor tiene un proceso asociado que convierte la entrada analogica del nivel de flu- 
jo en una serial digital. Dicho proceso envia este nivel de flujo, con el identificador del sen- 
sor, al bufer de datos del sensor. El proceso responsable del procesamiento de los datos toma 
los datos de este bufer, los procesa y los envia a un proceso de visualizacion para mostrarlos 
en una consola del operador. 

En sistemas de tiempo real que implican la adquisicion y el procesamiento de datos, las 
velocidades y periodos del proceso de adquisicion (el productor) y el proceso de procesa- 
miento (el consumidor) pueden no estar sincronizados. Cuando se requiere un procesamien- 
to significativo, la adquisicion de datos puede ser mas rapida que el procesamiento de los da- 
tos. Si solamente es necesario realizar calculos sencillos, el procesamiento puede ser mas 
rapido que la adquisicion de los datos. 

Para suavizar estas diferencias de velocidad, los sistemas de adquisicion de datos almace- 
nan los datos de entrada utilizando un bufer circular. El proceso que produce los datos (el pro- 



Sensores (cada flujo de datos es un valor del sensor) 



Figura 15.11 
Arquitectura 
generica de los 
sistemas de 
adquisicion de 
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Sensores de flujo de neutrones 




Figura 15.12 Adquisicion de datos del flujo de neutrones. 



ductor) anade informacion a este bufer, y el proceso que usa los datos (el consumidor) coge 
la informacion del bufer (Figura 15.13). 

Obviamente, se debe implementar la exclusion mutua para impedir que los procesos pro- 
ductor y consumidor accedan al mismo elemento del bufer al mismo tiempo. El sistema tam- 
bien debe asegurar que el productor no intente anadir informacion a un bufer lleno y que el 
consumidor no extraiga informacion de un bufer vacio. 

En la Figura 15.14, se muestraunaposible implementacion del bufer de datos comounob- 
jeto Java. Los valores en el bufer son del tipo Sensor Record, y hay dos operaciones definidas 
denominadas get y put. La operacion gettomaun elemento del bufer y la op eracion put ana- 
de un elemento al bufer. El constructor del bufer fija el tamano cuando se declaran los obje- 
tos del tipo CircularBuffer. 

El modificadorsynchronized asociado con los medotos gety put indicaque estos meto- 
dos no deberian ejecutarse al mismo tiempo. Cuando se llama a uno de estos metodos, el sis- 
lema en tiempo de ejecucion obtiene un candado sobre la instancia del objeto para asegurar 
que el otro metodo no puede cambiar la misma entrada en el bufer. Las llamadas de los me- 
todos wait y notify se utilizan para asegurar que no pueden anadirse elementos en un bufer 
lleno o extraer elemento de un biifer vacio. El metodo wait hace que el hilo de ejecucion que 
realiza dicha llamada se suspenda a si mismo hasta que otro hilo le comunique que deje de 
esperar. Esto se realiza llamando al metodo notify. Cuando se realiza una llamada a wait, se 
libera el candado del objeto protegido. El metodo notify despierta a uno de los hilos que esta 
esperando y hace que continue con su ejecucion. 



Figura 15.13 Un 

bufer circular para la 
adquisicion de 
datos. 
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intbufstze; 
jcnsoriwcora g sore , 
tntnumbefOCntnes^O; 
int front -0, back- 0; 

Grculw8uffer(intn){ 
bufsi»«n; 

store new Sensorftecoid fbuftize] ; 
}//Cirajurtufcr 

iynchronfawd»oid put (S«reorRecord rec ) thfoxw trtteniipted&CTption 
{ 

S ( numbtfOflEntries — bufsixe) 
w*0; 

store {back] new Semorftecord (recseraortd, recsensorUal) ; 
bade — back + 1 ; 
*(back— bufsbx) 
back-0; 

mimberOfEntries - numberOfEntrks + 1 ; 

notify 0; 
}//p* 

synchronized SensorRecoid get 0 throws Intemiptet&cception 
( 

Sensorftecord result* new SensorRecord (-1,-1); 
»(nombeKWntries— 0) 

result *■ store {front] '• 
front* front +1 ; 
if (front— bufsize) 
front* 0; 

numbciOKntnes ■ numbeiOfEi Anes 1 ; 

notify 0; 

return result; 
Figure 15.14 Una }//get 
implementacidn Java j // GrcularBuffer 
de un bufer circular. 



PUNTOS CLAVE 

• Un sistema de liempo real es un sistema software que debe lesponder a eventos en tempo real Su conec- 
cion no sob depends de tos resultados que produce sfcn tamblen del irnivriD en el que se pnducen dchos 
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• Un modelo general para la arquitectura de sistemas de tiempo real implica el asociar un proceso con cada cla- 
se de dispositivo sensory actuador. Tambien se requieren procesosadicionalesde coordination. 

• Eldisehoarquitectdnicodeun si stem a de tiempo real implica normalmente la organization del si stem a como 
un conjunto de procesos concurrentes que interactuan. 

Un sistema operativo de tiempo real es responsable del proceso y la gestion de los recursos. Siempre Inclu- 
ye un planif icador, que es el componente responsable de decidir que proceso deberia seleccionarse para su 
ejecucion . Las decisionesde planificacionse realizan utilizando lasprioridadesde tos procesos. 

• Los sistemas de mon ito rizac io n y control con suit an periodica me nte un conjunto desensoresque captan In- 
formacion det entorno del sistema. Estos llevan a cabo acciones, dependiendo de las lecturas de los senso- 
res, y envian ordenes a los actuadores. 

• Los sistemas de adquisicion de datos se organizan normalmente segun un modelo productor-consumidor. El 
proceso productor coloca los datos en un bufer circular, desde donde son consumidos por el proceso consu- 
midor. El bufer tambien se implementa como un proceso para eliminar los conflictos entre el productor y el 
consumidor. 



LECTURAS AD I C 1 0 N ALES 

Software Engineering for Real-Time Systems. Escrito desde el punto de vista de una ingenieria en lugar de una pers- 
pectiva de ciencia de la computacion, este libro es una buena gula practica para la ingenieria de sistemas de tiem- 
po real. Estudia mejor las cuestiones hardware que el libro de Burns y Wellings, por lo que es un complemento ex- 
celente a este. 0- Cooling, 2003, Addison-Wesley.) 

Real-time Systems and Programming Languages, 3rd edition. Un texto excelente y facil de entender que proporcio- 
na una amplia coberturade todos los aspectosde los sistemas de tiempo real. (A. Burns y A. Wellings, 2001, Addi- 
son-Wesley.) 

Doing Hard Time: Devetoping Real-Time Systems with UML, Objects Frameworks and Patterns. Este libro explica 
como pueden utilizarse las tecnicas orientadas a objetos en eldiseno de sistemas de tiempo real. Puesto que la ve- 
locidad det hardware cada vez es mayor, este libro se esta convirtiendo en una aproximacion cada vez mas viable al 
diseno de sistemas de tiempo real. (B. P. Douglass, 1999, Addison-Wesley.) 



EJERCICIOS 

15.1 Utilizando ejemplos, explique por que los sistemas de tiempo real tienen que implementarse normalmen- 
te utilizando procesos concurrentes. 

152 Explique por que una aproximacion orientada a objetos para el desarrollo del software puede no ser ade- 
cuada para sistemas de tiempo real. 

153 Dibuje modelos de maquina de estados del software de control para los siguientes sistemas: 

• Una lavadora automatica que tiene diferentes programas para distintos tipos de ropa. 

• El software para un reproductor de discos compactos. 
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• Un contestador auto ma tico de telefono que graba los mensajes entrantes y visualiza el numero de men- 
sajes aceptados en una pantalla de cristal liquido. El sistema deberia permitir al propietario del telefo- 
no descolgar, teclear una secuencia de numeros (identificados como tonos) y reproducir los mensajes 
grabados en el contestador. 

• Una maquina de bebidas que puede dispensar cafe con y sin leche y azucar. El usuario inserta una mo- 
neda y hace su seleccion presionando un boton de la maquina. Esto provoca la salida de una taza con 
cafe en polvo. El usuario coloca esta taza bajo un grifo, presiona otro boton y se suministra agua ca- 
liente. 

15.4 Usando las tecnicas de diseno de sistemas de tiempo real estudiadas en este capitulo, redisene el siste- 
ma de recogida de datos de la estacion meteorologica tratada en el Capitulo 14 como un sistema de esti- 
mulo-respuesta. 

15.5 Diseheuna arquitectura de procesos para un sistema demonitorizacionambientalque recoge datos de un 
conjunto de sensores de la calidad del aire situados en varios puntos de una ciudad. Hay 5.000 sensores 
organizados en 100 barrios. Cada sensor debe ser consultado cuatro veces por segundo. Cuando mas del 
30% de los sensores en un barrio particular indique que la calidad del aire esta por debajo de un nivel acep- 
table, se activan luces locales de advertencia. Todos los sensores devuelven las lecturas a una computa- 
dora central, que genera informes cada 15 minutos sobre la calidad del aire en la ciudad. 

15.6 Comente las ventajas e inconvenientes de Java como lenguaje de programacion para sistemas de tiempo 
real. ^Enquemedida los problemasdelaprogramaciondetiempo real con Java d esa pa rece ran cuando se 
utilicen procesadores mas rapidos? 

15.7 Un sistema de proteccion de trenes frena automaticamente el tren si el hmite de velocidad se excede en 
un tramo de via o si el tren entra en un tramo de via sehalizado con una luz roja (es decir, no se debe en- 
trar en ese tramo de via). Los detalles se muestran en la Figura 15.15. Identifique los estimulos que debe 
procesar el sistema de control de a bordo del tren y las respuestas asociadas a estos estimulos. 

15.8 Sugiera una posible arquitectura de procesos para este sistema. Documente esta arquitectura de proce- 
sos utilizando el esquema mostrado en la Figura 15.8, indicando claramente si los estimulos son periodi- 
cos 0 aperiodicos. 

15.9 Si un proceso periddico en el sistema de a bordo de proteccion del tren se utiliza para recoger datos de un 
transmisor situado en la via, icon que periodicidad debe planificarse para asegurar que el sistema garan- 
tiza la recogida de informacion del transmisor? Explique la respuesta. 

15.10 A usted se le ha solicitado trabajaren un proyecto de desarrollo de tiempo real para una aplicacion mili- 
tar, pero no tiene experiencia previa en proyectos de este dominio. Comente lo que, como ingeniero de soft- 
ware profesional, deberia hacer antes de comenzar a trabajar en el proyecto. 
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□ slstema adqulere Informaclon sobre el llmlte de velocldad de un tramo desde un 
transmlsor sttuado en la vfa, que conHnuamente emlte el Identfflcador del tramo y su 
llmlte de velocldad. □ mlsmo transmlsor tamblen emlte Informaclon sobre el estado de la 
serial que controla ese tramo de vfa. □ oempo requerido para emlHr el tramo de vfa y la 
Informaclon de la serial es de 50 mfllsegundos. 

□ tren puede reclblr Informaclon desde el transmlsor sttuado en la via cuando este a 
menos de 10 metres del transmlsor. 

La velocldad maxima del tren es de 180 km/h. 

Los sensores del tren proporclonan Informaclon sobre la velocldad actual del tren 
(actuallzada cada 250 mfllsegundos) y del estado del freno del tren (actuallzado cada 100 
mfllsegundos). 

SI la velocldad del tren excede de la velocldad llmlte del tramo actual en mas de 5 km/h, 
suena una alarma en la cablna del conductor. SI la velocldad del tren excede de la 
velocldad Ifmlte del tramo actual en mas de ID km/h, los frenos del tren se acclonan 
automatlcamente hasta que la velocldad este dentro de los llmltes permrUdos. Los frenos 
del tren deberfan acclonarse antes de 100 mfllsegundos desde que se detects la velocldad 
excesha del tren. 

SI el tren entra en un tramo de vfa senallzado con una luz roja, el slstema de protecclon 
del tren acclona los frenos y reduce la velocldad a cent. Los frenos del tren deberfan 
acclonarse antes de 100 mfllsegundos despues de que se reclba la serial de luz raja. 

El slstema conHnuamente actuahza una pantalla de estado en la cablna del conductor. 



Figura 15.15 

Description del 
slstema de 
protection de trenes. 
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Objetivos 

El objetivo de este capitulo es introducir algunos aspectos de 
diseno de las interfaces de usuario que son importantes para los 
ingenieros de software. Cuando haya leido este capitulo: 

• comprendera varios principios de diseno de las interfaces de 
usuario; 

• habra sido introducido a varios estilos de interaccion y 
entendera cuando estos son los mas apropiados; 

• comprendera cuando utilizar presentaciones graficas y 
textuales de la informacion; 

• conocera los aspectos implicados en las principales 
actividades en el proceso de diseno de las interfaces de 
usuario; 

• comprendera los atributos de usabilidad y habra sido 
introducido a los diversos enfoques de evaluacion de 
interfaces. 
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El diseno de sistemas informaticos abarca varias actividades que van desde el diseno de hard- 
ware hasta el de la interfaz de usuario. Aunque muchos especialistas a menudo trabajan en el 
diseno de hardware y en el diseno grafico de paginas web, normalmente solo las organiza- 
ciones grandes emplean disenadores especialistas de interfaces para sus aplicaciones software. 
Por tanto, los ingenieros de software a menudo deben tomar la responsabilidad de disenar la 
interfaz de usuario, asi como del diseno del software que implementa esa interfaz. 

Aun cuando los disenadores y programadores de software son usuarios competentes en la 
tecnologia utilizada en la implementacion de las interfaces, como las clases Swing de Java 
(Elliott et ai, 2002) o XHTML (Musciano y Kennedy, 2002), las interfaces de usuario que 
desarrollan a menudo son poco atractivas e inapropiadas para sus usuarios objetivo. Se anali- 
zara, por lo tanto, el proceso de diseno de interfaces de usuario en lugar del software que im- 
plementa estas interfaces. Debido a las limitaciones de espacio, solo se consideraran las in- 
terfaces graficas de usuario. No se trataran las interfaces que requieren una forma especial 
(aunque quiza muy simple) de visualizacion como las de telefonia movil, reproductores de 
DVD, televisores, copiadoras y maquinas de fax. Naturalmente, aqui solo se puede dar una 
introduccion al tema, por lo que para obtener mayor informacion sobre el diseno de interfa- 
ces de usuario se recomiendan los textos de Dix y otros (Dix etal., 2004), Weiss (Weiss, 2002) 
y Shneiderman (Shneiderman, 1998). 

Un diseno cuidadoso de la interfaz de usuario es parte fundamental del proceso de diseno 
general del software. Si un sistema software debe alcanzar su potencial maximo, es funda- 
mental que su interfaz de usuario sea disenada para ajustarse a las habilidades, experiencia y 
expectativas de sus usuarios previstos. Un buen diseno de la interfaz de usuario es critico para 
la confiabilidad del sistema. Muchos de los llamados «errores de usuario» son causados por 
el hecho de que las interfaces de usuario no consideran las habilidades de los usuarios reales 
y su entorno de trabajo. Una interfaz de usuario mal disenada significa que los usuarios pro- 
bablemente no podran acceder a algunas caracteristicas del sistema, cometeran errores y sen- 
tiran que el sistema les dificulta en vez de ayudarlos a conseguir cualquier objetivo para el que 
utilizan el sistema. 

Cuando se toman decisiones en el diseno de las interfaces de usuario, deben tenerse en 
cuenta las capacidades fisicas y mentales de las personas que utilizaran el software. Las li- 
mitaciones de espacio no permite tratar aqui en detalle los factores humanos, pero algunos fac- 
tores importantes que deben considerarse son los siguientes: 

1 . Las personas tienen una memoria limitada a corto plazo: podemos recordar instanta- 
neamente alrededorde siete elementos de informacion (Miller, 1957). Por lo tanto, si 
a los usuarios se les presenta demasiada informacion al mismo tiempo, es posible que 
no puedan asimilarla. 

2. Todos cometemos errores, especialmente cuando tenemos que manejar demasiada in- 
formacion o estamos estresados. Cuando los sistemas fallan y emiten mensajes de 
aviso y alarmas, a menudo aumentan el estres de los usuarios, incrementando asi la 
posibilidad de que cometan errores. 

3. Poseemos un amplio rango de capacidades fisicas. Unas personas ven y escuchan me- 
jorque otras, otras son daltonicas, y otras son mejores en manipulaciones fisicas. No 
se debe disenar para las propias capacidades y suponer que todos los otros usuarios 
seran capaces de adaptarse. 

4. Tenemos diferentes preferencias de interaccion. A algunas personas les gusta trabajar 
con imagenes, a otras con texto. La manipulacion directa es natural para algunas per- 
sonas, pero otras prefieren un estilo de interaccion basado en emitir comandos al sis- 
lema. 
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Estos factores humanos son la base para los principios de diseno que se muestran en la Figu- 
ra 16.1. Estos principios generales se aplican atodos los disefios de interfaces de usuario y nor- 
malmente se deben instanciar como directrices de diseno mas detalladas para organizaciones o 
tipos de sistema especificos. Los principios de diseno de las interfaces de usuario son tratados 
con mayor detalle por Dix y otros (Dix etai, 2004). Shneiderman (Shneiderman, 1998) da una 
listamas ampliade directrices mas especificaspara el diseno de las interfaces de usuario. 

El principio de familiaridad del usuario sugiere que los usuarios no deben ser obligados a 
adaptarse a una interfaz solo porque sea conveniente implementarla. La interfaz debe utilizar 
terminos familiares para los usuarios, y los objetos que el sistema manipula deben estardi- 
rectamente relacionados con el entorno de trabajo del usuario. Por ejemplo, si un sistema se 
disenapara serutilizado por controladores del trafico aereo, los objetos deben ser aviones, tra- 
yectorias de vuelo, aerofaros, etcetera. Las operaciones asociadas podrian ser incrementar o 
reducir la velocidad del avion, ajustar la posicion del avion y cambiar de altura. La imple- 
mentacion subyacente de la interfaz en lo que se refiere a archivos y estructuras de datos se 
debe ocultaral usuario final. 

E 1 principio de uniformidad de la interfaz de usuario significa que los comandos y menus 
del sistema deben tener el mismo formato, los parametros deben pasarse a todos los comandos 
de la misma forma, y la puntuacion de los comandos debe ser similar. Las interfaces uniformes 
reducen el tiempo de aprendizaje del usuario. Por lo tanto, el conocimiento aprendido en un co- 
mando o aplicacion es aplicable en otras partes del sistema o en aplicaciones relacionadas. 

La uniformidad de la interfaz a lo largo de las aplicaciones tambien es importante. En lo 
posible, los comandos con significados similares en aplicaciones diferentes se deben expre- 
sar de la misma forma. A menudo los errores se originan cuando el mismo comando del te- 
clado, como «Control+b», significa cosas diferentes en sistemas distintos. Porejemplo, en el 
procesador de textos que utilizo normalmente, «Control+b» significa poner en negrita el tex- 
to, pero en los programas graficos que utilizo para dibujar diagramas, «Control+b» significa 
poner el objeto seleccionado detras de otro objeto. Yo cometo errores cuando los utilizo al 
mismo tiempo y a menudo trato de poner en negrita el texto en un diagrama utilizando esta 
combinacion de teclas. Me confundo entonces cuando el texto desaparece detras del objeto 
que lo encierra. Normalmente, se puede evitar este tipo de errores si se siguen los metodos 
abreviados para las teclas de comandos definidos por el sistema operativo que utiliza. 
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Este nivel de uniformidad es de bajo nivel. Los disenadores de interfaces siempre deben tra- 
tar de conseguir este nivel en una interfaz de usuario. Algunas veces, la uniformidad de nivel 
alto tambien es deseable. Porejemplo, puede ser conveniente llevara cabo las mismas opera- 
ciones (como imprimir, copiar, etcetera) sobre todos los tipos de entidades del sistema. Sin em- 
bargo, Grudin (Grudin, 1989) senala que la uniformidad total no siempre es posible o desea- 
ble. Puede serrazonable implementarel borrado de un escritorio arrastrando las entidades aun 
cubo de basura, pero seria incomodo borrar el texto en un procesador de textos de esta forma. 

Desgraciadamente, los principios de familiaridad del usuario y uniformidad a veces son 
contradictorios. Idealmente, las aplicaciones con caracteristicas comunes deberian utilizar 
siempre los mismos comandos para acceder a estas caracteristicas. Sin embargo, esto puede 
chocar con los habitos del usuario cuando los sistemas se disenan para apoyar a un tipo de 
usuario en particular, como los disenadores graficos. Estos usuarios pueden tener que desa- 
rrollar sus propios estilos de interacciones, terminologiay convenciones de funcionamiento. 
Estas pueden estar en desacuerdo con los «estandares» de interaccion que son apropiados para 
aplicaciones mas generales como los procesadores de textos. 

El principio de minima sorpresa es apropiado debido a que las personas se irritan dema- 
siado cuando el sistema se comporta de forma inesperada. Cuando se utiliza un sistema, los 
usuarios construyen un modelo mental de la forma en que trabaja dicho sistema. Si una ac- 
cion en alguncontextoprovocaun tipo de cambio particular, es razonable esperarque la mis- 
ma accion en un contexto diferente cause un cambio comparable. Si sucede algo completa- 
mente diferente, el usuario se sorprende y confunde. Por lo tanto, los disenadores de interfaces 
deben intentar asegurar que las acciones comparables tengan efectos comparables. 

Las sorpresas en las interfaces de usuario a menudo se deben al hecho de que en muchas 
interfaces existen varios modos de trabajo (por ejemplo, el modo vista y el modo edicion), y 
el efecto de un comando es diferente dependiendo del modo. Es muy importante que, al di- 
senar una interfaz, se incluya un indicador visual que muestre al usuario el modo actual. 

El principio de recuperabilidad es importante debido a que los usuarios inevitablemente 
cometen errores cuando utilizan un sistema. El disefio de la interfaz puede minimizar estos 
errores (por ejemplo, los errores de teclado se evitan si se utilizan menus), pero los errores 
nunca pueden eliminarse completamente. Por consiguiente, se deben incluir recursos que 
permitan a los usuarios recuperarse de sus errores. Estos pueden ser de tres tipos: 

1. Confirmation de acciones destructivas. Si un usuario lleva a cabo una accion que es 
potencialrhente destructiva, el sistema deberia pedirle que confirme que esto es real- 
mente lo que desea antes de destruir cualquier informacion. 

2 . Proporcionar un recurso para deshacer. El recurso deshacer restablece el sistema al 
estado previo antes de que ocurriera la accion. Son utiles varios niveles de este recur- 
so debido a que los usuarios no siempre reconocen inmediatamente que han cometi- 
do un error. 

3 . Generar puntos de control. La generacion de puntos de control implica grabar el es- 
tado de un sistema en intervalos periodicos y permitirque el sistema se restaure des- 
de el ultimo punto de control. De esta forma, cuando se produce un error, los usuarios 
pueden retroceder a un estado previo y empezar de nuevo. En la actualidad, muchos 
sistemas incluyen la generacion de puntos de control para tratar los fallos del sistema 
pero, paradoj icamente, no permiten a los usuarios del sistema utilizarlos para recupe- 
rarse de sus propios errores. 

Un principio relacionado es el de asistencia al usuario. Las interfaces deben proporcionar 
asistencia al usuario o caracteristicas de ayuda. Estas se deben integraren el sistema y pro- 
porcionar diferentes niveles de ayuda y asesoramiento. Los niveles deben variar desde la in- 
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formacionbasicapara iniciarse con el sistema hastauna descripcion completa de las caracte- 
risticas del sistema. Los sistemas de ayuda se deben estructurar de forma que cuando el usua- 
rio requiera ayuda no se sienta saturado con la informacion. 

E 1 principio de diversidad de usuarios sefiala que, para muchos sistemas interactivos, pue- 
denexistirdiferentes tipos de usuarios. Algunos son usuarios casuales y tienen interaccion con 
el sistema ocasionalmente, mientras que otros son usuarios potenciales que utilizan el siste- 
ma durante varias horas todos los dias. Los usuarios casuales necesitan interfaces que los 
guien, pero los usuarios potenciales requieren metodos abreviados de forma que puedan inter- 
actuar con el sistema tan rapido como sea posible. Ademas, los usuarios pueden tener impe- 
dimentos de varios tipos y, si es posible, las interfaces deben poder adaptarse para hacer fren- 
te a esto. Por lo tanto, se podria incluir recursos para mostrar diferentes tamanos de texto, 
reemplazarel sonido con texto, permitirmodificarel tamafio de los botones, etcetera. Esto re- 
fleja la nocion de Diseno Universal (UD) (Preisery Ostoff, 2001), un principio de diseno cuyo 
objetivo es evitar excluir usuarios debido a elecciones de diseno irreflexivas. 

El principio de reconocimiento de la diversidad de usuarios puede estar en pugna con los 
otros principios de diseno de las interfaces, ya que algunos usuarios pueden preferiruna inter- 
accion muy rapida sobre, por ejemplo, la uniformidad de la interfaz. De forma similar, el ni- 
vel de ayuda requerido puede ser radicalmente diferente para distintos usuarios, y puede ser 
imposible desarrollar ayudas adecuadas para todos los tipos de usuario. Por lo tanto, se debe 
llegar a acuerdos para hacer compatibles las necesidades de estos usuarios. 

16.1 Asuntos de diseno 

Antes de abordar el proceso de diseno de la interfaz de usuario, se tratan algunos asuntos ge- 
nerales de diseno que tienen que ser considerados por los disenadores de interfaces de usuario. 
Fundamentalmente, el disefiadorde una interfaz de usuario se plantea dos cuestiones clave: 

1 . ^Como debe interactuar el usuario con el sistema informatico? 

2. ^Como se debe presentar la informacion del sistema informatico al usuario? 

Una interfaz de usuario coherente debe integrar la interaccion del usuario y la presentacion 
de la informacion. Esto puede serdificil debido a que los disenadores tienen que encontrarun 
termino medio entre los estilos mas adecuados de interaccion y presentacion para la aplica- 
cion, la formacion y experiencia de los usuarios del sistema, y el equipo disponible. 

16.1.1 Interaccion del usuario 

La interaccion del usuario significa emitir comandos y datos asociados al sistema informati- 
co. En las primeras computadoras, la unica forma de hacer esto era a traves de una interfaz de 
linea de comandos, y se utilizaba un lenguaje de proposito especifico para comunicarse con 
la maquina. Sin embargo, este enfoque se oriento a los usuarios expertos y actualmente se han 
desarrollado varios enfoques que son mas faciles de utilizar. Shneiderman (Shneiderman, 
1998) ha clasificado estas formas de interaccion en cinco estilos principales: 

1. Manipulation directa. El usuario interactua directamente con los objetos de la panta- 
11a. La manipulacion directa normalmente implica un dispositivo apuntador (un raton, 
un lapiz optico, un trackball o, en una pantalla tactil, un dedo) que indica el objeto a 
manipulary la accion, lacual especifica lo que se debe hacer con ese objeto. Porejem- 
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pio, para borrar un archivo, se puede hacer clic en un icono que represente a ese ar- 
chives y arrastrarlo a un icono de un cubo de basura. 

2. Selection de menus. El usuario selecciona un comando de una lista de posibilidades 
(un menu). Tambien puede seleccionar otro objeto de la pantalla por manipulacion di- 
recta, y el comando actua sobre el. En este enfoque, para borrar un archivo, seleccio- 
naria el icono del archivo y despues el comando de borrado. 

3. Rellenado deformularios. El usuario rellena los campos de un formulario. Algunos 
campos pueden llevar menus asociados, y el formulario puede tener «botones» de ac- 
cion que, cuando sepresionan, hacenque se inicie alguna accion. Normalmente nouti- 
lizara este enfoque para implementar la interfaz de operaciones como el borrado de ar- 
chivos. Hacer esto implicaria introducir el nombre del archivo en el formulario y 
despues «presionar» un boton de borrar. 

4. Lenguaje de comandos. E 1 usuario emite un comando especial y los parametros aso- 
ciados para indicar al sistema que hacer. Para borrar un archivo, se teclearia un co- 
mando de borrado con el del archivo como parametro. 

5. Lenguaje natural. El usuario emite un comando en lenguaje natural. Normalmente esto 
es unfront-end para un lenguaje de comandos; el lenguaje natural se analiza y traduce 
a comandos del sistema. Para borrar un archivo, se teclearia «borrar el archivo xxx» . 
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Cada uno de estos estilos de interaccion tiene ventajas y desventajas y es mas adecuado 
para diferentes tipos de aplicaciones y usuarios (Shneiderman, 1998). La Figura 16.2 mues- 
tra las principales ventajas y desventajas de estos estilos y sugiere los tipos de aplicacion don- 
de podrian utilizarse. 

Por supuesto, estos estilos de interaccion se pueden mezclar, utilizando varios estilos en la 
misma aplicacion. Porejemplo, Microsoft Windows permite la manipulacion directa de los 
iconos que representan a los archivos y carpetas, la seleccion de comandos basados en me- 
nus, y para comandos como los de configuracion, los usuarios deben rellenar un formulario 
de proposito especifico que se les muestra. 

En principio, es posible separar el estilo de interaccion de las entidades subyacentes que 
se manipulan a traves de la interfaz de usuario. Esta foe la base para el modelo de Seeheim 
(Pfaff y ten Hagen, 1985) sobre la gestion de interfaces de usuario. En este modelo, se sepa- 
ra la presentacion de la informacion, la gestion del dialogo y la aplicacion. En la realidad, este 
es un modelo ideal mas que un modelo practico, aunque es ciertamente posible tener interfa- 
ces separadas para los diferentes tipos de usuarios (usuarios casuales y usuarios experimen- 
tados) que interactuan con el mismo sistema subyacente. Esto se ilustra en la Figura 16.3. la 
cual muestra una interfaz de lenguaje de comandos y una interfaz grafica para un sistema ope- 
rativo como Linux. 

Las interfaces de usuario basadas en web se fundan en el soporte proporcionado por HTML 
o XHTML (el lenguaje de descripcion de paginas utilizado por las paginas web) junto con len- 
guajes como Java, los cuales pueden asociar programas con los componentes de una pagina. 
Debido a que normalmente estas interfaces basadas en web son disenadas por usuarios ca- 
suales, la mayoria de ellas utiliza interfaces basadas en formularios. Es posible construir in- 
terfaces de manipulacion directa en web, pero esta es una tarea compleja de programacion. 
Ademas, debido a los diferentes niveles de experiencia de los usuarios de la web y al hecho 
de que provienen de muchas culturas diferentes, es dificil establecer una metafora de la in- 
terfaz de usuario para la interaccion directa que sea umversalmente aceptada. 

Para ilustrarel diseno de la interaccion de usuario basada en web, se presenta el enfoque 
utilizado en el sistema LIB SYS donde los usuarios pueden acceder a documentos de otrasbi- 
bliotecas. Existen dos operaciones fundamentals que se necesita soportar: 

1. Busqueda de documentos, en la que los usuarios utilizan las funciones de busqueda 
para encontrar los documentos que necesitan. 

2. Petition de documentos, en la que los usuarios solicitan que el documento se descar- 
gue en su maquina o servidor local para imprimirlo. 
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La interfaz de usuario del L I B S Y S se implementa utilizando un navegador web, por lo que, 
dado que los usuarios deben proporcionar informacion al sistema como el identificador del 
documento, sus nombres y detalles de autorizacion, tiene sentido utilizar una interfaz basada 
en formularios. La Figura 16.4 muestra unposible disefio de la interfaz para la busqueda de 
componentes del sistema. 

En interfaces basadas en formularios, el usuario proporciona toda la informacion requeri- 
da y despues inicia la accion pulsando un boton. Los campos de los formularios pueden ser 
menus, campos de entrada libre de texto o botones de radio. En el ejemplo del LIB S Y S , un 
usuario selecciona la coleccion a buscar de un menu de colecciones al que se puede acceder 
(la opcion por defecto es «Todas», que significa buscar todas las colecciones) y teclea la fra- 
se de busqueda en un campo de entrada libre de texto. El usuario elige el campo del archivo 
de la biblioteca de un menu (la opcion por defecto es «Titulo») y selecciona un boton de ra- 
dio para indicar si los terminos de busqueda deben ser adyacentes en el archivo. 



16.1.2 Presentation de la informacion 

Todos los sistemas interactivos tienen que proporcionar alguna forma de presentar la infor- 
macion a los usuarios. La presentacion de la informacion puede ser simplemente una repre- 
sentacion directa de la informacion de entrada (por ejemplo, texto en un procesador de tex- 
tos) o presentar la informacion graficamente. Unabuenapautade diseno es mantener separado 
el software requerido para la presentacion de la informacion misma. Separar el sistema de pre- 
sentacion de los datos nos permite cambiar la representacion en la pantalla del usuario sin te- 
ner que cambiar el sistema de calculo subyacente. Esto se ilustra en la Figura 16.5. 

El enfoque M V C (Figura 16.6), el cual estuvo disponible por primera vez en Smalltalk 
(Goldberg y Robson, 1983), es una forma efectiva para permitir representaciones multiples 
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de datos. Los usuarios pueden interactuar con cada presentacion utilizando un estilo apropia- 
do a esta. Los datos a visualizar se encapsulan en un modelo de objetos. Cada modelo de 
objetos puede tener asociados varios objetos vista diferentes donde cada vista es una repre- 
sentacionde visualizaciondiferente del modelo. 

Cada vista tiene un objeto controlador asociado que maneja las entradas del usuario y la 
interaccion de los dispositivos. Por lo tanto, un modelo que representa datos numericos pue- 
de tener una vista que represente tos datos como un histograma y una vista que presente los 
datos como una tabla. El modelo se puede editar cambiando los valores en la tabla o alargan- 
do o acortando las barras en el histograma. Esto se trata con mayor detalle en el Capitulo 18. 
donde se explica como puede utilizarse el patron Observer para implementar el marco de tra- 
bajo MVC. 

Para encontrar la mejor presentacion de la informacion, se necesita conocer a los usuarios 
de la informacion y saber como utilizaran el sistema. Cuando se decide como presentar la in- 
formacion, deben tenerse presentes las siguientes cuestiones: 

1. ^,E1 usuario esta interesado en informacion precisa o en las relaciones entre los valo- 
res de los datos? 

2. iCon que frecuencia cambian los valores de la informacion? ^Se indicaran de forma 
inmediata al usuario los cambios en un valor? 

3. ^El usuario debe llevar a cabo alguna accion en respuesta a los cambios de la infor- 
macion? 

4. ^El usuario necesita interactuar con la informacion visualizada a traves de una inter- 
faz de manipulacion directa? 

5. ^La informacion que se va a visualizar es textual o numerica? ^Son importantes los 
valores relativos de los elementos de la informacion? 

No se debe suponerque por utilizargraficos se hacen las vistas mas interesantes. Los gra- 
ficos ocupan un valioso espacio en lapantalla (unacuestion importante en los dispositivos mo- 
viles) y pueden tardar bastante tiempo en descargarse si el usuario esta trabajando con una co- 
nexion de acceso telefonico lenta. 

Dependiendo de la aplicacion, la informacion que no cambia durante una sesion se puede 
presentar tanto grafica como textualmente. La presentacion textual ocupa menos espacio en 
la pantalla, pero no se puede leer de un vistazo. Debe distinguirse la informacion que no cam- 
bia de la informacion dinamica utilizando diferentes estilos de presentacion. Porejemplo,po- 
dria presentarse toda la informacion estatica con un tipo de letra o color particular, o podria 
asociarse con un icono de «informacion estatica». 
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Se debe utilizar texto para presentar la informacion cuando se requiere que esta sea preci- 
sa y cambie de forma relativamente lenta. Si los datos cambian rapidamente o si las relacio- 
nes entre los datos mas que los valores exactos de los datos son importantes, se debe presen- 
tar la informacion graficamente. 

Por ejemplo, considere un sistema que registra y resume las cifras de venta mensuales de 
unacompaflia. LaFigura 16.7 ilustracomo presentar la misma informacion como texto o en 
forma grafica. Normalmente, los gerentes que estudian las cifras de ventas estan mas intere- 
sados en las tendenciaso anomalias que en los valores exactos. La presentacion grafica de esta 
informacion, como un histograma, hace que las cifras anomalas en marzo y en mayo desta- 
quen sobre lasotras. La citada figura tambien ilustracomo la presentacion textual ocupa me- 
nos espacio que la presentacion grafica de la misma informacion. 

En las salas de control o los tableros de mandos como los del salpicadero de un coche, la 
informacion que se muestra representa el estado de algun otro sistema (por ejemplo, la alti- 
tud de un avion) y esta cambiando continuamente. Las vistas digitales que cambian constan- 
temente pueden ser confusas y molestas ya que los lectores no pueden leer y asimilar la 
informacion antes de que cambie. Por lo tanto, la informacion numerica que variadinamica- 
mente se representa mejor de forma grafica utilizando una representacion analogica. Si es 
necesario, las vistas graficas pueden complementarse con una vista digital precisa. En la F i - 
gura 16.8 se muestran diferentes formas de presentar informacion numerica dinamica. 
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Las vistas analogicas continuas dan al usuario una sensacion de valor relativo. En la Figu- 
ra 16.9, los valores de la temperatura y la presion son aproximadamente los mismos. Sin em- 
bargo, la vista grafica muestra que la temperatura esta cerca de su valor maximo mientras que 
la presion no alcanzael 25% de su maximo. Con un valor digital solamente, el usuario nece- 
sita conocer los valores maximos y calcular mentalmente el estado relativo de la lectura. En 
situaciones de estres, pensar adicionalmente puede conducir a errores humanos que generan 
problemas, por lo que las vistas pueden mostrar lecturas anormales. 

Cuando se tienen que presentar grandes cantidades de informacion, se pueden utilizar vi- 
sualizaciones abstractas que vinculen los elementos de los datos relacionados. Esto puede re- 
velar relaciones que no son obvias en los datos sin formato. Se debe ser consciente de las po- 
sibilidades de visualizacion, especialmente cuando la interfaz de usuario del sistema debe 
representar entidades fisicas. He aqui algunos ejemplos de visualizaciones de datos: 

1. La informacion meteorologica, recogidade varias fuentes, se muestra como unmapa 
meteorologico con isobaras, frentes meteorologicos, etcetera. 

2. El estado de una red telefonica se muestra graficamente como un conjunto vinculado 
de nodos en un centro de administracion de la red. 

3. El estado de una planta quimica se visualiza mostrando las presiones y temperaturas 
en un conjunto vinculado de depositos y tuberias. 

4. Un modelo de una molecula se muestra y manipula en tres dimensiones utilizando un 
sistema de realidad virtual. 

5. Un conjunto de paginas web se muestra como un arbol hiperbolico (Lamping etal., 
1995). 

Shneiderman (Shneiderman, 1998) ofrece una buena vision general de los enfoques para 
la visualizacion ademas de identificar las clases de visualizacion que se pueden utilizar. Es- 
tas incluyen la visualizacion de datos utilizando presentaciones en dos y tres dimensiones y 
en forma de arboles o redes. La mayoria de estas se refieren a la visualizacion de grandes 
cantidades de informacion gestionada en una computadora. Sin embargo, la utilizacion mas 
comun de la visualizacion en las interfaces de usuario es para representar alguna estructura 
fisica, como la estructura molecular de una nueva droga, las conexiones en una red de tele- 
comunicaciones, etcetera. Las presentaciones en tres dimensiones que pueden utilizar equi- 
po de realidad virtual especial son particularmente eficaces para producir visualizaciones. 
Una forma muy eficaz para interactuar con los datos es la manipulacion directa de estas vi- 
sualizaciones. 

Ademas del estilo de presentacion de la informacion, se debe pensar detenidamente en los 
colores utilizados en la interfaz. El color puede mejorar las interfaces de usuario ayudando a 
los usuarios a comprendery manejar la complejidad. Sin embargo, es facil utilizar el color de 
forma erronea para crear interfaces visualmente poco atractivas y propensas a errores. Shnei- 
derman da 14 pautas clave para la utilizacion efectiva del color en las interfaces de usuario. 
Las mas importantes son: 
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1 . Limitar el numero de colores utilizadosy ser conservador en la forma de utilizarlos. 

No deben utilizarse mas de cuatro o cinco colores diferentes en una ventana y no mas 
de siete en una interfaz del sistema. Si se utilizan demasiados, o si son demasiado vi- 
vos, la vista puede ser confusa. Algunos usuarios pueden considerar que las grandes 
cantidades de colores son molestas y visualmente cansadas. Tambien es posible la con- 
fusion en el usuario si los colores no se utilizan de manera uniforme. 

2. Utilizar un catnblo de color para mostrar un cambio en el estado del sistema. Si una 
vista cambia de color, debe significar que ha ocurrido un evento importante. Asi, en 

un indicadordel nivel de combustible, se podria utilizar un cambio de color para in- 
dicarunabajada. Resaltar el color es muy importante en las vistas complejas donde se 
muestran cientos de entidades distintas. 

3 . Utilizar el codigo de colores para apoyar la tarea que los usuarios estdn tratando de 
jlevara cabo. Si los usuarios tienen que identificar instancias anomalas, se deben re- 
saltar estas instancias; si tambien tienen que descubrir similitudes, se deben resaltar 
estas utilizando un color diferente. 

4. Utilizar el codigo de colores de una forma conscientey uniforme. S i una parte de un 
sistema muestra los mensajes de error en rojo (por ejemplo), todas las demas partes 
deben mostrarlos de igual forma. El rojo no se debe utilizarpara nada mas. Si se hace, 
es posible que el usuario interprete la vista en rojo como un mensaje de error. 

5. Ser cuidadoso al utilizar pares de colores. Debido a la fisiologiadel ojo, laspersonas 
no pueden enfocar el rojo y el azul simultaneamente. La vista cansada es una conse- 
cuencia probable de una vista en rojo sobre azul. Otras combinaciones de colores pue- 
den ser tambien visualmente molestas o dificiles de leer. 

En general, se debe utilizar el color para la accion de resaltar, pero no se debe asociar sig- 
nificados con colores particulares. Aproximadamente el 10% de los hombres son daltonicos 
y pueden malinterpretar el significado. Las percepciones humanas del color son diferentes, y 
existen convenciones distintas en diferentes profesiones acerca del significado de colores par- 
ticulares. Los usuarios con conocimientos diferentes inconscientemente pueden interpretar el 
mismo color de formas distintas. Por ejemplo, para un conductor, el rojo por lo general sig- 
nificapeligro. Sin embargo, paraunquimico, el rojo signifies. caliente. 

Ademas de presentar la informacion de la aplicacion, los sistemas tambien se comuni- 
can con los usuarios a traves de mensajes que proporcionan informacion sobre los errores 
y el estado del sistema. La primera experiencia de un usuario de un sistema software pue- 
de ser cuando el sistema presenta un mensaje de error. Los usuarios inexpertos pueden em- 
pezar su trabajo, cometer un error inicial y de forma inmediata tienen que comprender el 
mensaje de error resultante. Esto puede ser bastante dificil para los ingenieros de software 
expertos. Es a menudo imposible para los usuarios inexpertos o casuales del sistema. En la 
Figura 16.10 se muestran los factores que deben tenerse en cuenta al diseftar mensajes del 
sistema. 

Se debe prever la formacion y experiencia de los usuarios cuando se disefian mensajes de 
error. Por ejemplo, suponga que un usuario del sistema es una enfermera en una sala de cui- 
dados intensivos de un hospital. La observacion del paciente se lleva a cabo mediante un sis- 
tema informatico. Para verel estado actual del paciente (ritmo cardiaco, temperatura, etcete- 
ra), la enfermera selecciona «mostrar» de un menu e introduce el nombre del paciente en un 
recuadro, como se muestra en la Figura 16.1 1. 

En este caso, vamos a suponer que la enfermera ha escrito incorrectamente el nombre del 
paciente y ha tecleado «MacDonald» en lugarde «McDonald». El sistema genera un mensa- 
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Factor D«scripci6n 



Contexto Donde sea posible, los mensajes generados por el sistema 

deben reflejar et contexto actual del usuario. En to posfote, 
el sistema debe ser consdente de b que esta hadendo 
el usuario y generar mensajes retacionados con su acnvidad 
actual 



Experienda 



Nivd 



Estito 



Culture 



Al aumentar la famtliaridad de los usuarios con el sistema, tambien 
se aumenta su molestia por los mensajes largos y «sigrHficativos». 
Sin embargo, los principiantes tienen dificultades en comprender 
los mensajes cortos y concisos del problema. Se deben piopordonar 
ambos tipos de mensajes y pemiibr al usuario contralar la concision de 
los mensajes. 

los mensajes se deben adaptor a las habWdades del usuario, ad como 
a su experienda. Los mensajes pan las dfcrentes dases de usuario se 
pueden expresar de difererttes formas dependiende de la twminologla 
que el lector utitice. 

los mensajes deben ser positives en vez de negatives. Deben ester 
escritos en modo active y no en pasiua No deben ser insuftante^ 
o tratar de ser graciosos. 

En la medioa de to posible, el disenador de mensajes debe estar 
familidrizado con la cuttura dd pais donde se vende d sistema. Existen 
distintas d'rferencias cuhurales entre Europe, Asia y America. Un mensaje 
adecuado en una cuttura podrla no aoeptarse en otta. 



je de error. Los mensajes de error siempre deben ser formales, concisos, uniformes y cons- 
tructivos. No deben ser ofensivos ni tener sonidos asociados u otro tipo de ruidos que pueden 
desconcertar al usuario. En la medida de lo posible, el mensaje debe sugerir como se podria 
corregir el error. El mensaje de error debe vincularse a un sistema de ayuda en linea sensible 
al contexto. 

La Figura 16.12 muestra ejemplos de mensajes de error bien y mal diseftados. El mensaje 
de la izquierda esta mal disenado. Es negativo (acusa al usuario de haber cometido un error), 
no se adapta a las habilidades y al nivel de experiencia del usuario, y no tiene en cuenta la in- 
formacion del contexto. No sugiere como se podria rectificar la situacion. Utiliza terminos es- 
pecificos del sistema (identificador de paciente) en vez de un lenguaje orientado al usuario. 
El mensaje de la derecha es mejor. Es positivo, lo que da a entender que el problema es del 
sistema y no del usuario. Identifica el problema en terminos entendibles para la enfermera y 
ofrece una forma facil para corregir el error pulsando un simple boton. El sistema de ayuda 
estadisponible si se necesita. 



344 CAPITULO 16 • Diseno de interfaces de usuario 



Mensaje de error orientado al sistema 



Mensaje de error orientado al usuario 




Error #27 

Identrficador de paciente 
no vdlido 



R. MacDonald no es un paciente registrado 

Haga die en Pacientes para una lista de pacientes 

Haga die en Reintentar para introducir nuevamente un nombre de padente 
Haga die en Ayuda para mis informadbn 



^Ac«pta^ ^anceUr ^ ^ Paci<nt»s j ^ Ayuda ^ ^ Reintenta r) ^Cancels r^ 



Figura 16.12 Mensajes de error orientados al sistema y al usuario. 



16.2 El proceso de diseno de la interfaz de usuario 



El diseno de la interfaz de usuario (UI) es un proceso iterativo donde los usuarios interac- 
luan con los disenadores y prototipos de la interfaz para decidir las caracteristicas, organi- 
zacion, aparienciay funcionamiento de la interfaz de usuario del sistema. A veces, se cons- 
truye el prototipo de la interfaz por separado en paralelo con otras actividades de la ingenieria 
del software. Mascomunmente, en especial cuando se utilizaundesarrollo iterativo, el dise- 
no de la interfaz de usuario se lleva a cabo de forma incremental conforme se desarrolla el 
software. En ambos casos, sin embargo, antes de que empiece la programacion, debe haber 
desarrollado e, idealmente, probado algunos disenos en papel. 

En la Figura 16.13 se ilustrad proceso de diseno general de laUI. Existen tres actividades 
esenciales en este proceso: 

1 . Andlisis del usuario. En el proceso de analisis del usuario, se desarrolla una compren- 
sion de las tareas que este realiza, su entorno de trabajo, los otros sistemas que utiliza, 
como interactuan con el resto de las personas en su trabajo, etcetera. Paraproductos con 
una diversa variedad de usuarios, se debe intentar desarrollar esta comprension a traves 
de grupos de discusion, pruebas con usuarios potenciales y ejercicios similares. 

2. Prototipado del sistema. E 1 diseno y desarrollo de la interfaz de usuario es un proce- 
so iterativo. Aunque los usuarios pueden hablar de las facilidades que necesitan de una 
interfaz, es muy dificil para ellos ser especificos hasta que ven algo tangible. Por lo 
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tanto, se deben desarrollar prototipos del sistema y exponerlos a los usuarios, quienes 
pueden entonces guiar la evolucion de la interfaz. 
3. Evaluation de la interfaz. Aunque obviamente se habra hablado con los usuarios du- 
rante el proceso de prototipado, tambien se debe tener una actividad de evaluacion mas 
formalizada donde se recopile informacion sobre las experiencias reales de los usua- 
rios con la interfaz. 

Esta seccion se centra en el analisis del usuario y en la evaluacion de la interfaz, con solo 
una breve descripcion de las tecnicas especificas de prototipado de interfaces de usuario. En 
el Capitulo 17 se tratan asuntos mas generales sobre el prototipado y tecnicas de prototipado. 

La confeccion de agendas del disefio de la Ul dentro del proceso del software depende, has- 
ta cierto punto, de otras actividades. Como se vio en el Capitulo 7, se puede utilizar la cons- 
truccion de prototipos como parte del proceso de la ingenieria de requerimientos y. en este caso, 
tiene sentido empezar el proceso de disefio de la UI en esa etapa. En los procesos iterativos, 
analizados en el Capitulo 17, el disefio de la Ul se integracon el desarrollo del software. Como 
el software mismo, se puede tener que rcfactorizur y redisefiar la UI durante el desarrollo. 

163 Analisis del usuario 

Una actividad critica del disefio de la UI es el analisis de las actividades del usuario que deben 
ser soportadas por el sistema informatico. Si no se entiende lo que los usuarios quieren hacer 
con el sistema, no se podra llevar a cabo un disefio real y eficaz de la interfaz de usuario. Para 
desarrollar esta comprension, puede utilizar tecnicas como el analisis de tareas, estudios etno- 
graficos, entrevistas de usuarios y observaciones o. comunmente, una mezcla de todas ellas. 

Un reto para los ingenieros involucrados en el analisis de usuarios es encontrar una forma 
de describir los analisis de modo que comuniquen la esencia de las tareas a los otros disefia- 
dores y a los usuarios mismos. Notaciones como los diagramas de secuencia de U M L pueden 
describir las interacciones del usuario y son ideales para comunicarse con los ingenieros de 
software. Sin embargo, otros usuarios pueden pensar que estos diagramas son demasiado tec- 
nicos y no intentaran comprenderlos. Debido a que es muy importante implicar a los usuarios 
en el proceso de disefio, normalmente habra que desarrollar escenarios en lenguaje natural 
para describir las actividades del usuario. 

La Figura 16.14 es un ejemplo de un escenario en lenguaje natural que se podria haberdes- 
. arrollado durante el proceso de especificacion y disefio del sistema LIB SYS . Describe una si- 

tuacion en la que no existe el LIB SYS y una estudiante necesita obtener informacion de otra 
biblioteca. De este escenario, el disefiador puede ver varios requerimientos: 

Jane es ina esto d bnte de estucfos raj ejo s o s que esta p w p ara nrb ina redaction 
sobre la awpfeclua hda y como esta ha estate HMda por las coshiifMS 
lejejosas. Rara ayudarie a entender esto, le gustarfa acceder a imageries de 
detafles de edflcfos nofahteSi p&o no puede onoortaar nanfa en su bfcloteca bnaL 
Se aoaca al bHotecario para gyoneriesus recesfclariesyeste lesuejae 
termlnos de busqueda que podria utlzar. Tambien le sugae bMotec as en Nuera 
DeH y borates que podrian tener este material, por lo que enban a bs catalogos 
de la bMoteca y buscan uHfaando estos termlnos. Bvuenban sI&mtb faente de 
material y haoen una petition de f otocoplas de bs Imagenes con bs derates 
arqultectonlcos, para que se bs envfen dtectamen b a Jane. 



Figura 16.14 
Un escenario de 
interaction en una 
biblioteca. 
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1 . Los usuarios podrian no conocer los terminos de busqueda apropiados. Pueden nece- 
sitar tener acceso a formas de ayudarles para elegir terminos de busqueda. 

2. Los usuarios tienen que poder seleccionar colecciones para buscar. 

3 . Los usuarios necesitan poder llevar a cabo busquedas y solicitar copias de material re- 
levante. 

No se debe esperar que el analisis del usuario genere requerimientos de interfaces de usua- 
rio muy especificos. Normalmente, el analisis ayuda a comprender las necesidades y preocu- 
paciones de los usuarios del sistema. Conforme se conoce mejor como trabajan y cuales son 
sus preocupaciones y restricciones, estas pueden tenerse en cuenta en el diseno. Esto signifi- 
caque es mas probable que los disefios iniciales (los cuales, de todos modos, se perfecciona- 
ran a traves del prototipado) sean aceptados por los usuarios y, por lo tanto, convencerlos para 
implicarlos en el proceso de perfeccionamiento del diseno. 

16.3.1 Tecnlcas de analisis 

Como se sugirio en la seccion anterior, existen tres tecnicas base de analisis del usuario: ana- 
lisis de tareas, entrevistas y cuestionarios, y etnografia. El analisis de tareas y las entrevistas 
se centran en el individuo y en su trabajo, mientras que la etnografia adopta una perspectiva 
mas general y considera como interactuan las personas, como organizan su entorno de traba- 
jo y como cooperan para resolver problemas. 

Existen varias clases de analisis de tareas (Diaper, 1989), pero la mas comunmente utili- 
zada es el Analisis de Tareas Jerarquico (HTA). El HTA file desarrollado en un principio para 
ayudar a escribir manuales de usuario, pero tambien se puede utilizar para identificar lo que 
hacen los usuarios para alcanzar algun objetivo. En el HTA, una tarea de alto nivel se divide 
en subtareas, y se identifican planes que especifican lo que pasarian en una situacion especi- 
fica. Empezando con un objetivo del usuario, se dibuja unajerarquia que muestra que se tie- 
ne que hacer para alcanzar ese objetivo. La Figura 16.15 ilustra este enfoque utilizando el es- 
cenario de la biblioteca introducido en la Figura 16.14. En la notacion del HTA, una linea 
debajo de la caja normalmente indica que no se descompondra en subtareas mas detalladas. 

Laventajadel HTA sobre los escenarios en lenguaje natural es que obligaaconsiderarcada 
una de las tareas y decidir si estas se deben descomponer. Con los escenarios en lenguaje na- 
tural, es facil omitir tareas importantes. Los escenarios tambien se hacen largos y pesados de 
leer si se desea afiadirles muchos detalles. 

El problema con este enfoque para describir las tareas del usuario es que es mas apropia- 
do para tareas que sonprocesos secuenciales. La notacion se hace dificil cuando se intentamo- 
delar tareas que implican actividades entrelazadas o simultaneas o que conllevan muchas sub- 
tareas. Ademas, el HTA no registra por que las tareas se hacen de una forma en particular o 
restringen los procesos del usuario. Se puede obtener una vision parcial de las actividades del 
usuario a traves del HTA, pero se necesita informacion adicional para desarrollar una com- 
prension mas completa de los requerimientos de diseno de la UI. 

Normalmente, se recopila informacion para el HTA a traves de la observacion y de entre- 
vistas con los usuarios. En este proceso de entrevistas, se puede recopilar parte de esta infor- 
macion adicional y registrarla al lado de los analisis de tareas. Cuando se realizan entrevistas 
para descubrir lo que los usuarios hacen realmente, se deben disenar las entrevistas de forma 
que los usuarios puedan proporcionar informacion que ellos (en vez del entrevistador) pien- 
sen que es importante. Esto significa que no hay que cenirse rigidamente a una lista prepara- 
da de preguntas. Mas bien, las preguntas deben ser abiertas y animar a los usuarios a que di- 
gan por que hacen las cosas ademas de lo que realmente hacen. 
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Figura 16.15 
Analisis de tareas 
jerarquico. 
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Las entrevistas, por supuesto, no son solo una forma de obtener informacion para el ana- 
lisis de tareas: son una tecnica general para obtener informacion. Se pueden complementar 
las entrevistas individuales con entrevistas engrupo o grupos de discusion. Laventajade uti- 
lizar grupos de discusion es que los usuarios se estimulan entre si para proporcionar infor- 
macion y pueden terminar discutiendo diferentes formas que han desarrollado de utilizar los 
sistemas. 

El analisis de tareas se centra en como trabajan los individuos, pero, por supuesto, la ma- 
yorla del trabajo es realmente cooperativo. Las personas trabajanjuntas para conseguir un ob- 
jetivo, y los usuarios encuentran dificil discutir como se lleva a cabo esta colaboracion. Por 
lo tanto, la observacion directa de como trabajan y utilizan los sistemas informaticos los 
usuarios es una importante tecnica adicional de analisis del usuario. 

Un enfoque para la observacion directa que ha sido utilizado en una amplia variedad de es- 
cenarios es la etnografia (Suchman, 1983; Hughes etal., 1997; Crabtree, 2003). La etnogra- 
fia se trato en el Capitulo 7 como una tecnica que apoya a la ingenieria de requerimientos. Los 
etnografos observan de cerca como trabajan las personas, como se relacionan entre si y como 
utilizan los recursos de su lugar de trabajo para ayudarlas en el. La ventaja de la etnografia es 
que los etnografos pueden observar las acciones intuitivas y las colaboraciones informales, 
que pueden entonces provocar nuevas discusiones sobre el trabajo. 

Como ejemplo de como puede influir la etnografia en el diseno de las interfaces de usua- 
rio, la Figura 16.16 es un fragmento de un informe de un estudio etnografico de los controla- 
dores del trafico aereo en el cual estuve implicado (Bentley etal., 1992). Estabamos intere- 
sados en el diseno de la interfaz para un sistema de control del trafico aereo (ATC) mas 
automatizado y aprendimos dos cosas importantes de estas observaciones: 

1. Los consoladores no podlan ver todos los vuelos de un sector (esta era larazon por la 
que extendlan tiras en la mesa). Por lo tanto, debemos evitar utilizar vistas que em- 
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El control del traflco aereo Impllca varlos «Juegos» de controles donde las Juegos 
que controlan sectores adyacentes de) espaclo aereo estan flskamente sltuados 
unos al lado de otros. Los vuelos en un sector se representan medlante tlras de 
papel que se ajustan en rejlllas de madera en un orden que refleja su posklan en 
el sector. SI no hay suflclentes ranuras en la rejllla (por ejemplo, cuando hay 
mucho traflco en el espaclo aereo), los controladores extlenden las tlras en la 
mesa delante de la rejllla. Cuando observabamos a los controladores, nos dlmos 
cuenta de que con regularldad mlraban las rejlllas de tlras del sector adyacente. Se 
lo comentamos y les preguntamos por que lo hadan. Respondleron que, cuando el 
controlado? adyacente tlene tlras en su mesa, slgnlflca que estan entrando muchos 
vuelos en sus sectores. Por k) tanto, Intentaban Incrementar la velocldad de los 
avlones en el sector para «despe|ar el espaclo» para los avlones entrantes. 



pleen barras de desplazamiento donde los vuelos desaparezcan por la parte superior o 
inferior de la vista. 

2. La interfaz debe tener alguna forma de comunicar a los controladores cuantos vuelos 
hay en los sectores adyacentes de forma que puedan planificar su carga de trabajo. 

Comprobar los sectores adyacentes era una accion automatica del controlador y es muy 
probable que no la hubieran mencionado en las discusiones sobre el proceso del ATC. Des- 
cubrimos estos importantes requerimientos solo a traves de la observacion directa. 

Ninguna de estas tecnicas de analisis del usuario, por si misma, proporciona una vision 
completa de lo que realmente hacen los usuarios. Estas son enfoques complementarios que 
deben utilizarse para ayudar a entender lo que hacen los usuarios y a comprender mejor lo que 
podria ser un diseno de la interfaz de usuario apropiado. 

16.4 Prototipado de la interfaz de usuario 

Debido a la naturaleza dinamica de las interfaces de usuario, las descripciones textuales y los 
diagramas no son adecuados para expresar los requerimientos de estas. El prototipado evolu- 
tivo o exploratorio con la implicacion de los usuarios finales es la linica forma practica de di- 
senar y desarrollar interfaces graficas de usuario para sistemas software. Implicar al usuario 
en el proceso de diseno y desarrollo es un aspecto fundamental del diseno centrado en el usua- 
rio (Normal y Draper, 1986), un criterio de diseno para sistemas interactivos. 

El proposito del prototipado es permitir a los usuarios adquirir una experiencia directa con 
la interfaz. La mayoria de nosotros encuentra dificil pensar de forma abstracta sobre una in- 
terfaz de usuario y explicar exactamente que deseamos. Sin embargo, cuando se nos presen- 
tan ejemplos, es facil identificar las caracteristicas que nos gustan y las que no. 

Idealmente, cuando se esta construyendo el prototipo de una interfaz de usuario, se debe 
adoptar un proceso de prototipado en dos etapas: 

1. Al principio del proceso, hay que desarrollar prototipos en papel — maquetas de los 
disenos de laspantallas — y mostrarselos a los usuarios finales. 

2. Entonces, se perfecciona el diseno y se desarrollan prototipos automatizados cada vez 
mas sofisticados, y se ponen a disposicion de los usuarios para realizar pruebas y si- 
mulacion de actividades. 



Figura 16.16 
Un informe de 
observaciones del 
control del trafico 
aereo. 
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La construccion de prototipos en papel es un enfoque poco costoso y sorprendentemente 
efectivo para el desarrollo de prototipos (Snyder, 2003). No se necesita desarrollar ningun 
software ejecutable y los disenos no tienen por que hacerse conforme a estandares profesio- 
nales. Se pueden hacer versiones en papel de las pantallas del sistema con las que interactu- 
an los usuarios y se puede disenar un conjunto de escenarios que describan como se podria 
utilizar el sistema. Conforme se desarrolla un escenario, hay que esbozar la informacion que 
se mostraray las opciones disponibles a los usuarios. 

Se debe trabajar entonces a traves de estos escenarios con los usuarios para simular la ma- 
nera en que se utilizara el sistema. Es una forma efectiva de ver las reacciones iniciales de los 
usuarios a un diseno de la interfaz, la informacion que necesitan del sistema y como interac- 
tuaran normalmente con el sistema. 

Como alternativa, se puede utilizar una tecnica basada en storyboards para presentar el di- 
seflo de la interfaz. Un storyboard es una serie de esbozos que ilustran una secuencia de inter- 
acciones. Esto es menos manejable, pero puede serde mayor utilidad cuando se presentan las 
propuestas de interfaz a grupos en vez de a personas individuales. 

Despues de los experimentos iniciales con los prototipos en papel, se debe implementar un 
prototipo software del diseno de la interfaz. El problema, por supuesto, es que se necesita que 
el sistema tenga alguna funcionalidad con la cual los usuarios puedan interactuar. Si se esta cons- 
truyendo el prototipo de la Ul al principio del proceso de desarrollo del sistema, puede ser que 
esta funcionalidad no este disponible. Para evitar este problema, se puede utilizar el prototipa- 
do de «Mago de Oz» (si no se ha visto la pelicula, vease la pagina web para una explicacion). 
En este enfoque, los usuarios interacluan con lo que parece serun sistema informatico, pero sus 
entradas se canalizan a una persona oculta que simula las respuestas del sistema. Pueden hacer 
esto directamente o utilizando algun otro sistema para calcular las respuestas requeridas. En este 
caso, no se necesita tener ningun software ejecutable aparte de la interfaz de usuario propuesta. 

Se pueden llevar a cabo experimentos de prototipado adicionales utilizando tanto un enfo- 
que evolutivo como un enfoque desechable. Estos enfoques de prototipado analizan en el Ca- 
pitulo 17, donde tambien se describen varias tecnicas que se pueden emplearpara el prototi- 
pado y el desarrollo rapido de aplicaciones. Existen tres enfoques que pueden utilizarse para 
el prototipado de interfaces de usuario: 

1 . Enfoque dirigido por secuencias de comandos. Si solamente se necesita estudiar ide- 
as con los usuarios, se puede utilizar un enfoque dirigido por secuencias de coman- 
dos, como el que encontrara en Macromedia Director. En este enfoque, se crean pan- 
tallas con elementos visuales, como botones y menus, y se asocia una secuencia de 
comandos con estos elementos. Cuando el usuario interactua con estas pantallas, se 
ejecuta la secuencia de comandos y se presenta la siguiente pantalla, que les muestra 
los resultados de sus acciones. No hay implicada ninguna aplicacion logica. 

2. Lenguajes de programacion visuales. Los lenguajesdeprogramac ion visuales, como 
Visual Basic, incorporan un potente entorno de desarrollo, acceden a una gran varie- 
dad de objetos reutilizables y a un sistema de desarrollo de interfaces de usuario que 
permite crear interfaces de forma rapida, con componentes y secuencias de comandos 
asociados con los objetos de la interfaz. Se describen los sistemas de desarrollo vi- 
suales en el Capitulo 17. 

3 . Prototipado basado en Internet. Estas soluciones, basadas en navegadores web y en 
lenguajes como Java, ofrecen una interfaz de usuario hecha. Se afiade funcionalidad 
asociando segmentos de programas Java con la informacion a visualizar. Estos seg- 
mentos (llamados applets) se ejecutan automaticamente cuando se carga la pagina en 
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el navegador. Este enfoque es una forma rapida de desarrollar prototipos de interfaces 
de usuario, pero existen restricciones inherentes impuestas por el navegador y por el 
modelo de seguridad de Java. 

Obviamente, el prototipado esta muy relacionado con la evaluacion de la interfaz. Es im- 
probable que las evaluaciones formales sean economicas para los primeros prototipos, ya que 
lo que se esta intentando conseguir en esta etapa es una «evaluacion formativa» en la que se 
buscan formas de mejorar la interfaz. Conforme el prototipo se hace mas completo, pueden 
utilizar tecnicas de evaluacion sistematica, como se vera en la siguiente seccion. 



16.5 Evaluacion de la interfaz 

La evaluacion de la interfaz es el proceso de evaluar la forma en que se utiliza una interfaz y 
verificar que cumple los requerimientos del usuario. Por lo tanto, debe ser parte del proceso 
de verificaciony validacionde los sistemas software. Neilsen (Neilsen, 1993), en su libro so- 
bre ingenieria de usabilidad, incluye un buen capitulo sobre este tema. 

De forma ideal, una evaluacion se debe llevar a cabo contra una especificacion de la usa- 
bilidad basada en atributos de la usabilidad, como se muestra en la Figura 16.17. Las metri- 
cas de estos atributos de usabilidad se pueden idear. Por ejemplo, en una metrica de aprendi- 
zaje, se podria enunciar que a un operador familiarizado con las tareas implemeniadas le debe 
serposible utilizar el 80% de la funcionalidad del sistemadespues de tres horasde formacion. 
Sin embargo, es mas comun especificar la usabilidad (si es que se especifica del todo) de for- 
ma cuantitativa en vez de utilizar metricas . Por lo tanto, el diseflador tiene que utilizar su cri- 
terio y experiencia en la evaluacion de las interfaces. 

La evaluacion sistematica del diseno de la interfaz de usuario puede serun proceso caro 
que implica a cientificos cognoscitivos y disefiadores graficos. Es posible que se tenga que di- 
senary realizarun numero estadisticamente importante de experimentos con los usuarios ti- 
picos. Se puede necesitarel uso de laboratorios construidos especialmente con equipos de su- 
pervision. Una evaluacion de la interfaz de usuario de este tipo es economicamente poco 
realistapara sistemas desarrollados porpequenas organizaciones con recursos limitados. 

Existen varias tecnicas menos costosas y sencillas en la evaluacion de interfaces que pue- 
den identificar deficiencias especificas en el diseno de interfaces: 

1. Cuestionarios que recopilan informacion de lo que opinan los usuarios de la interfaz. 

2. Laobservacionde los usuarios cuando trabajan con el sistemay «piensan en voz alta» 
de como tratan de utilizar el sistema para llevar a cabo alguna tarea. 



Atributo 



Figura 16.17 
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3. «Instantaneas» de videos del uso tipico del sistema. 

4. La inclusion de codigo en el software que recopila informacion de los recursos mas 
utilizados y de los errores mas comunes. 

Examinar a los usuarios utilizando un cuestionario es una forma relativamente economica 
de evaluaruna interfaz. Las preguntas deben serprecisas mas que generales. No es de utili- 
dad hacer preguntas como «Por favor, haga comentarios sobre la usabilidad de la interfaz», 
puesto que las respuestas probablemente variaran tanto que no se descubrira ninguna tenden- 
cia comun. En su lugar, las preguntas especificas como «Por favor, indique el valor en una es- 
cala de 1 a 5 de cual es la comprension de los mensajes de error. Un valor 1 significa muy cla- 
ra y 5 significa incomprensible» son mejores. Son mas faciles de responder y es mas probable 
que proporcionen informacion util para mejorar la interfaz. 

Cuando estan rellenando el cuestionario, a los usuarios se les debe preguntar sobre su ex- 
periencia y conocimientos. Esto permite al disefiador saber si los usuarios con cierto tipo de 
conocimientos tienen problemas con la interfaz. Los cuestionarios se pueden utilizaraun an- 
tes de que este disponible el sistema ejecutable si se construyen y evaluan maquetas en papel 
de la interfaz. 

La evaluacion basadaen laobservacion sencillamente comprende observarcomo utilizan 
el sistema los usuarios, ver los recursos que utilizan, los errores cometidos, etcetera. Esto se 
puede complementar con sesiones de «pensar en voz alta», en las cuales los usuarios conver- 
san sobre lo que tratan de hacer, que piensan del sistema y como tratan de utilizarlo para llevar 
a cabo sus objetivos. 

Utilizar equipo de video de relativamente bajo coste significa que puede grabar las sesio- 
nes de usuario para su analisis posterior. Un analisis completo por medio de video es caro y 
requiere un equipo de evaluacion especializado con varias camaras enfocadas al usuario y a 
lapantalla. Sin embargo, la grabacion en video de algunas operaciones especificas puede ayu- 
dar a detectar los problemas. Se deben utilizar otros metodos de evaluacion para detectar que 
operaciones provocan dincultades al usuario. 

El analisis de las grabaciones permite al disefiador descubrir si la interfaz requiere dema- 
siado movimiento de las manos (un problema con algunos sistemas es que los usuarios deben 
mover frecuentemente sus manos del teclado al raton) y ver si son necesarios movimientos 
forzados del ojo. Una interfaz que requiera muchos cambios de enfoque puede implicar que 
los usuarios cometan mas errores y pierdan partes de la visualizacion. 

Instrumentar codigo que recopile estadisticas de utilizacion permite mejorar las interfaces 
de varias formas. Se pueden detectar las operaciones mas comunes. Las interfaces se pueden 
reorganizarpara que sean mas rapidas de seleccionar. Por ejemplo, si se utilizan menus con- 
textuales o descendentes, las operaciones mas frecuentes se deben ubicar en la parte superior 
del menu y las operaciones destructivas en la pane inferior. La instrumentacion de codigo tam- 
bien permite que los comandos propensos a errores se detecten y modifiquen. 

Finalmente, es facil proporcionar a los usuarios un comando que puedan utilizar para en- 
viar mensajes al disefiador de la herramienta. Esto hace que los usuarios sientan que sus opi- 
niones son tenidas en cuenta. Asi, el disefiador de la interfaz y otros ingenieros pueden obte- 
ner una rapida retroalimentacion de los problemas particulares. 

Ninguno de estos enfoques relativamente simples para la evaluacion de la interfaz de usua- 
rio es infalible y probablemente no detectan todos los problemas de las interfaces de usuario. 
Sin embargo, las tecnicas se pueden utilizar con un grupo de voluntarios sin un gran desem- 
bolso de recursos antes de que se entregue el sistema. Asi, se pueden descubrir y corregir mu- 
chos de los peores problemas del disefio de las interfaces de usuario. 
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PUNTOS CLAVE 

• Los principios de las interfaces de usuario que abarcan la familiaridad del usuario, la uniformidad, la mfnima 
sorpresa, la recuperabilidad, la guia al usuario y la diversidad de usuarios ayudan aguiareldisenode las In- 
terfaces de usuario. 

• Los estilos de interaction con un sistema software incluyen la manipulacion directa, los sistemas de menus, 
el rellenado de formularios, los lenguajes de comandos y el lenguaje natural. 

• Lavisualizacidngraficadelainformacidnsedebeutilizarcuandose pretenda presentartendenciasyva lores 
aproximados. La visual izac ion digital solo se debe utilizar cuando se requiere precision. 

• El color se debe utilizar con moderacidnyde forma uniforme en las interfaces de usuario. Los disehadores de- 
ben tener en cuenta el hecho de que un importante numero de personas son daltdnicas. 

• El proceso de diseno de la interfaz de usuario incluye subprocesos relacionados con el analisis, el prototipa- 
do de la interfaz y la evaluacion de esta. 

El objetivo del analisis del usuario es dar a conocera losdisenadoreslas formas de trabajar reales de los usua- 
rios. Debe utilizar diferentes tec nicas — a nalisisdetareas, entrevistasyo bserva c id n — durante el analisis del 
usuario. 

• El desarrollo de prototipos de interfaces de usuario debe ser un proceso en etapas con prototipos iniciales ba- 
sados en versiones en papel de la interfaz que, despues de una evaluacion y retroalimentacidn inicial, se uti- 
lizan como base para prototipos automatizados. 

• Los objetivos de la evaluacion de interfaces de usuario son obtener una retroalimentacidn decdmosepuede 
mejorar el diseno de la Ul y evaluarsi una interfaz cumple sus requerimientos de usabilidad. 



LECTURAS ADICIONALES «H\/Iikr ! % KHHBHHMMalalil 

Human-Computer Interaction, 3rd ed. Un buen texto general cuyo punto fuerte se centra en los temas de diseno y 
el trabajo cooperativo. (A. Dix etai, 2004, Prentice-Hall.) 

Interaction Design. Este libro se centra en el diseno de la interaccion con los sistemas informaticos. Presenta gran 
parte del mismo material que Human-Computer Interaction pero de una forma bastante diferente. Ambos estan bien 
escritos y merece la pena leerlos. 0- Preece efai, 2002, John Wiley & Sons.) 

«Usability Engineering)). Este numero especial de IEEE Software incluye varios articulos sobre usabilidad escritos es- 
pecialmente para lectores con conocimientos sobre ingenieria del software. [lEEESoftware, 18(1), enero 2001.J 



ejercicios .J 1 1 1 1 1 1 lii cvw. HHalaHHHHMili 

16.1 En la Seccion 16.1 se sugirio que los objetos que manipulan los usuarios se deben obtener de su dominio 
y no del dominio de la informatica. Sugiera objetos adecuados para ios siguientes usuarios y sistemas: 

• Un ayudante de almacen que utiliza un catalogo de piezas automatizado. 

• Un piloto de aviones que utiliza un sistema de supervision de seguridad de aviones. 
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• Un gerente que manipula una base de datos financiera. 

• Un policia que utiliza un sistema de control de coches patrulla. 

162 Sugiera situaciones donde no sea adecuado o posible proveeruna interfaz de usuario uniforme. 

163 iQue factores deben tenerse en cuenta cuando se disefia una interfaz basada en menus para sistemas del 
tipo de un cajero automatico (ATM) de un banco? Redacte un comentario critico sobre la interfaz de un ATM 
que utilice. 

164 Sugiera formas en las que podria adaptar la interfaz de usuario de un sistema de comercio electronico, 
como una libreria en linea o una tienda de discos, a usuarios que tienen problemas visuales o de control 
muscular. 

16.5 Sefiale las ventajas de la visualizacion grafica de la informacion y sugiera cuatro aplicaciones donde sea 
mas apropiado utilizar vistas graficas en vez de vistas digitales de informacion numerica. 

16.6 ^Cuales son las pautas a seguir cuando se utiliza color en una interfaz de usuario? Sugiera como utilizar 
el color de forma mas efectiva en la interfaz de alguna aplicacion empleada frecuentemente. 

16.7 Considere los mensajes de error producidos por MS-Windows, Linux, Mac Os o algun otro sistema opera- 
tivo. Sugiera como mejorar estos mensajes. 

16.8 Escriba posibles escenarios de interaccion para los siguientes sistemas: 

• La utilizacion de un servicio basado en web de reserva de entradas para el teatro con el fin de solicitar 
entradas y pagarlas mediante tarjeta de credito. 

• La solicitud de las mismas entradas utilizando una interfaz sobre telefono movil. 

• La utilizacion de un conjunto de herramientas CASE para crearun modelo de objetos de un sistema soft- 
ware (veanse los Capitulos 8 y 14) y la generacion automatica de codigo del modelo. 

16.9 <Tin que circunstancias podria utilizar el prototipado de «Mago de Oz»? ^Para que tipo de sistemas es 
inapropiado este enfoque? 

16.10 Disene un cuestionario que le permita recoger informacion sobre la interfaz de usuario de alguna herra- 
mienta (como un procesador de textos) con la que este familiarizado. Si es posible, distribuya este cues- 
tionario a varios usuarios y trate de evaluar los resultados. ^Que dicen estos sobre el disefio de la interfaz 
de usuario? 

16.11 Comente si es etico jmplementar software para controlar su utilizacion sin decides a los usuarios que se 
esta controlando su trabajo. 

16.12 ^Cuales son los puntos eticos a los que podrian enfrentarse los disefiadores de interfaces cuando tratan 
de compaginar las necesidades de los usuarios finales de un sistema con las necesidades de la organiza- 
cion que esta pagando por el sistema a desarrollar? 



I DESARROLLO 



Capitulo 17 Desarrollo rapido de software 

Capitulo 18 Reutilizacion del software 

Capftulo 19 Ingenien'a del software basada en componentes 

Capitulo 20 Desarrollo de sistemas cn'ticos 

Capitulo 21 Evolucion del software 



Cuando por prime ra vezse establecio la ingenieria del software como una disciplina, el 
proceso de desarrollo de la mayoria de los sistemas era un proceso de escribir un pro- 
grama basado en una especif icacion del diseno. Se utilizaban lenguajes de programa- 
cion imperativos como C, FORTRAN o Ada. En los textos de ingenieria del software, los 
capitulos sobre el desarrollo de software se centraban principalmente en las buenas 
practicas de programacion. 

En la actualidad existen diferentes formas de desarrollar software. Entre ellas se en- 
cuentran la programacion original en lenguajes como C++ o Java, la generacion de se- 
cuenciasdecomandos,laprogramacidnde bases de datos, la generacion de programas 
a traves de herramientas CASE, y la ingenieria del software basada en la reutilizacion. 
A cl e in a s . se esta reconociendofinalmente el hecho deque existe una distincion real en- 
tre el desarrollo y el mantenimiento, y estamos empezando a pensar en el desarrollo 
como la primera etapa en un proceso de la evolucion del programa. Para reflejar estos 
desarrollos, se ha incluido esta parte nueva en el libro, centrada en las tecnicas de des- 
arrollo. Existen cinco capitulos en esta parte: 

1. El Capitulo 17 es un capitulo nuevo que describe las tecnicas para el desarrollo 
rapido de software. En el entorno de negocios de hoy dia significa que las com- 
panias necesitan que su software se entregue rapidamente para que puedan res- 
ponder a nuevos desafiosyoportunidades. En este capitulo, se analizan los m e - 
todos agiles de desarrollo, centrando la atencion de modo especial en la 
programacion extrema. Ta m biensedescribenentornosparaeldesarrollorapido 
deaplicacionesyla adecuada utilizacion del prototipado de sistemas. 

2. Los Capitulos 18 y 19 tratan de la ingenieria del software basada en la reutiliza- 
cion. Durante los ultimos anos, la reutilizacion del software se ha hecho cada vez 
mascomunyel desarrollo basado en la reutilizacion esactualmenteunenfoque 
dominante en la ingenieria del software. El Capitulo 18 presenta una vision 
general de la reutilizacion del software yel desarrollo con reutilizacion. El Capi- 
tulo 19 se centra en la ingenieria del software basada en componentes, inclu- 
yendo la composicion de componentes y el proceso CBSE. 

3. El Capitulo 20 continua la exposicion de los sistemas criticos que esta presente 
en todo el libro. Se tratan varios enfoques de desarrollo para conseguir la confia- 
bilidad del sistema, incluyendo la evitacion de defectos y la tolerancia a los mis- 
mos, y se muestra como las construcciones y tecnicas de programacion se pue- 
den utilizar para conseguir la confiabilidad. En la parte final de este capitulo, se 
vuelve al tema de la arquitectura del software y se describen los enfoques arqui- 
tectonicospara la tolerancia a defectos. 

4. El Capitulo 21 trata sobre la evolucion del software. Loscambiosson inevitables 
en todos los sistemas software y, en vez de considerar el proceso de cambio como 
una actividad separada, pienso que tiene sentido considerarlo como una conti- 
nuacion del desarrollo inicial del software. En este capitulo, se estudia la inevita- 
bitidad de la evolucion, el mantenimiento del software, los procesos de la evolu- 
cion y la toma de decisiones para la evolucion de los sistemas heredados. 
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Objetivos 

El objetivo de este capitulo es describir varios enfoques para el 
desarrollo de software pensados para la entrega rapida del 
software. Cuando haya leido este capitulo: 

• entendera como un enfoque de desarrollo de software 
iterativo e incremental conduce a una entrega mas rapida de 
un software mas util; 

• entendera las diferencias entre los metodos de desarrollo 
agiles y los metodos de desarrollo de software que dependen 
de la documentacion de las especificaciones y disefios; 

• conocera los principios, practicas y algunas de las limitaciones 
de la programacion extrema; 

• entendera como se puede utilizar el prototipado para ayudar a 
resolver requerimientos y disefiar incertidumbres cuando se 
tiene que utilizar un enfoque de desarrollo basado en la 
especificacion. 

Contenidos 

17.1 Metodos agiles 

17.2 Programacion extrema 

17.3 Desarrollo rapido de aplicaciones 

17.4 Prototipado del software 
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Actualmente, los negocios operan en un entorno global que cambia rapidamente. Tienen que 
responder a nuevas oportunidades y mercados, condiciones economicas cambiantes y la apa- 
ricion de productos y servicios competidores. El software es parte de casi todas las operaciones 
de negocio, por lo que es fundamental que el software nuevo se desarrolle rapidamente para 
aprovechar nuevas oportunidades y responder a la presion competitiva. Por lo tanto, actualmente 
el desarrollo y entrega rapidos son a menudo los requerimientos mas criticos de los sistemas 
software. De hecho, muchas companias estan dispuestas a una perdida en la calidad del software 
y en el compromiso sobre los requerimientos en favor de una entrega rapida del software. 

Debido a que estas companias operan enun entorno cambiante, a menudo es practicamente 
imposible obtenerun conjunto completo de requerimientos del software estables. Los reque- 
rimientos que se proponen cambian inevitablemente, porque a los clientes les resulta imposi- 
ble predecir como afectara un sistema a la manera de trabajar, como interactuara con otros sis- 
temas y que operaciones de los usuarios se deben automatizar. Es posible que los 
requerimientos reales solo queden claros cuando se haya entregado el sistema y los usuarios 
hayan adquirido experiencia. 

Los procesos de desarrollo del software basados en una completa especificacion de los re- 
querimientos y posterior diseno, construccion y pruebas del sistema no se ajustan al desarro- 
llo rapido de aplicaciones. Cuando los requerimientos cambian o cuando se descubren pro- 
blemas con ellos, el diseno o implementacion del sistema se tiene que volver a realizar o 
probar. Como consecuencia, normalmente se prolonga en el tiempo un proceso en cascada 
convencional o basado en la especificacion y el software definitivo se entrega al cliente mu- 
cho tiempo despues de que fuera inicialmente especificado. 

En un entorno de negocios que se mueve con rapidez, esto puede causar verdaderos pro- 
blemas. Para cuando este disponible el software, la razon original de su adquisicion puede 
haber cambiado tan radicalmente que el software sea en realidad inutil. Por lo tanto, en par- 
ticular para los sistemas de negocio, los procesos de desarrollo que se basan en el desarrollo 
y entrega rapidos de software son esenciales. 

Los procesos de desarrollo rapido de software estan disefiados paraproducir software util 
de forma rapida. Generalmente, son procesos iterativos en los que se entrelazan la especifi- 
cacion, el diseno, el desarrollo y las pruebas. El software no se desarrollay utiliza en su tota- 
lidad, sino en una serie de incrementos, donde en cada incremento se incluyen nuevas fun- 
cionalidades al sistema. Aunque existen muchos enfoques para el desarrollo rapido de 
software, comparten las mismas caracteristicas fundamentales: 

1. Los procesos de especificacion, diseno e implementacion son concurrentes. No exis- 
te una especificacion del sistema detallada, y la documentacion del diseno se minimi- 
za o es generada automaticamente por el entorno de programacion utilizado para im- 
plementar el sistema. El documento de requerimientos del usuario define solamente 
las caracteristicas mas importantes del sistema. 

2. El sistema se desarrolla en una serie de incrementos. Los usuarios finales y otros sta- 
keholders del sistema participan en la especificacion y evaluacion de cada incremen- 
to. Pueden proponer cambios en el software y nuevos requerimientos que se deben im- 
plementar en un incremento posterior del sistema. 

3 . A menudo se desarrollan las interfaces de usuario del sistema utilizando un sistema de 
desarrollo interactivo que permite que el diseno de la interfaz se cree rapidamente di- 
bujando y colando iconos en la interfaz. El sistema puede generar una interfaz basada 
en web para un navegador o una interfaz para una plataforma especifica como Micro- 
soft Windows. 
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El desarrollo incremental, introducido en el Capitulo4, implicaproduciry entregar el soft- 
ware en incrementos mas que en un paquete unico. Cada iteracion del proceso produce un nue- 
vo incremento del software. Las dos ventajas principales de adoptar un enfoque incremental 
para el desarrollo del software son: 

1. Entrega acelerada de los servicios de! cliente. En los incrementos iniciales del siste- 
ma se pueden entregar las funcionalidades de alta prioridad para que los clientes pue- 
dan aprovechar el sistema desde el principio de su desarrollo. Los clientes pueden ver 
sus requerimientos en la practica y especificar cambios a incorporar en entregas pos- 
teriores del sistema. 

2. Compromiso del cliente con el sistema. Los usuarios del sistema tienen que estar im- 
plicados en el proceso de desarrollo incremental debido a que tienen que proporcio- 
nar retroaljmentacion sobre los incrementos entregados al equipo de desarrollo. Su 
participacion no solo significa que es mas probable que el sistema cumpla sus reque- 
rimientos, sino que tambien los usuarios finales del sistema tienen que hacer un com- 
promiso con el y conseguir que este llegue a funcionar. 

En la Figura 17.1 se ilustra un modelo de proceso general para el desarrollo incremental. 
Observe que las etapas iniciales de este proceso se centran en el diseflo arquitectonico. Si no 
se considera la arquitectura al principio del proceso, es probable que la estructura general del 
sistema sea inestable y se degrade conforme se entreguen nuevos incrementos. 

El desarrollo incremental del software es un enfoque mucho mejor para el desarrollo de la 
mayoriade los sistemas de negocio, comercio electronico y personales porque reflejael modo 
fundamental al que todos nosotros tendemos al resolver problemas. Rara vez encontramos una 
solucion completa a un problema por adelantado, pero nos movemos hacia una solucion en 
una serie de pasos, dando marcha atras cuando nos damos cuenta de que hemos cometido un 
error. 

Sin embargo, puede haber verdaderos problemas con este enfoque, particularmente en las 
grandes companias con procedimientos bastante rigidos y en organizaciones donde el des- 
arrollo del software normalmente se subcontrata con un contratista exterior. Los principales 
problemas con el desarrollo iterativo y la entrega incremental son: 




Figura 17.1 Un proceso de desarrollo iterativo. 
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1. Problentas de administration. Las estructuras de administracion del software para sis- 
temas grandes se disenan para tratar con modelos de proceso del software que gene- 
ran entregas periodicas para evaluar el progreso. Los sistemas desarrollados incre- 
mentalmente cambian tan rapido que no es rentable producir una gran cantidad de 
documentaciondel sistema. Ademas, el desarrollo incremental muchas veces puede 
requerir el uso de tecnologias desconocidas para asegurar una entrega mas rapida del 
software. A los administradores puede resultarles dificil utilizar al personal existente 
en los procesos de desarrollo incremental puesto que carecen de las habilidades re- 
queridas. 

2. Problentas contractuales. El modelo contractual normal entre un cliente y un des- 
arrollador de software se basa en la especificacion del sistema. Cuando no existe tal 
especificacion, puede ser dificil disefiarun contrato para el desarrollo del sistema. Los 
clientes pueden estar descontentos con un contrato que simplemente pague a los desa- 
rrolladores por el tiempo invertido en el proyecto, ya que puede conducir a que el sis- 
tema se desarrolle lentamente y se sobrepase el presupuesto; los desarrolladores pro- 
bablemente no aceptaran un contrato con precio fijo debido a que no pueden controlar 
los cambios requeridos por los usuarios finales. 

3. Problentas de validation. En un proceso basado en la especificacion, la verificacion y 
la validacion estan pensadas para demostrar que el sistema cumple su especificacion. 
Un equipo independiente de V & V puede empezar a trabajar tan pronto como este dis- 
ponible la especificacion y puede preparar pruebas enparalelo con la implementacion 
del sistema. Los procesos de desarrollo iterativo intentanminimizarladocumentacion 
y entrelazan la especificacion y el desarrollo. Por lo tanto, la validacion independien- 
te de los sistemas desarrollados incrementalmente es dificil. 

4. Problentas de mantenimiento. Los cambios continuos tienden a corromper la estruc- 
tura del cualquier sistema software. Esto significa que cualquiera, aparte de los des- 
arrolladores originales, puede tener dificultades para entender el software. Una forma 
de reducir este problema es utilizar refactorizacion, donde se mejoran continuamente 
las estructuras del software durante el proceso de desarrollo. Esto se expone en la Sec- 
cion 17.2, donde se trata la programacion extrema. Ademas, si se utiliza tecnologia es- 
pecializada, como los entornos R A D (descritos en la Seccion 17.3), para ayudaral des- 
arrollo rapido del prototipo, la tecnologia R AD puede convertirse en obsoleta. Por lo 
tanto, puede ser dificil encontrar personas que tengan los conocimientos requeridos 
para dar mantenimiento al sistema. 

Por supuesto, existen algunos tipos de sistemas donde el desarrollo y entrega rapidos no 
son el mejor enfoque. Estos son sistemas muy grandes donde el desarrollo puede implicar 
equipos que trabajan en diferentes lugares, algunos sistemas embebidos donde el software de- 
pende del desarrollo del hardware y algunos sistemas criticos en los que se deben analizar 
todos los requerimientos para verificar las interacciones que puedan comprometer la seguri- 
dad o proteccion del sistema. 

Estos sistemas, por supuesto, sufren los mismos problemas de requerimientos inciertos y 
cambiantes. Por lo tanto, para abordar estos problemas y conseguir algunos de los beneficios 
del desarrollo incremental, se puede utilizar un proceso hibrido en el que se desarrolle de for- 
ma iterativa un prototipo del sistema y se utilice como una plataforma para experimentar con 
los requerimientos ydisefiodel sistema. Con laexperienciaadquiridacon el prototipo, se pue- 
de tener una mayor seguridad de que los requerimientos cumplen las necesidades reales de 
los stakeholders del sistema. 



17.1 • Metodos agiles 361 



Se utiliza aqui el termino prototipado para expresar un proceso iterativo para desarrollar 
un sistema experimental que no esta destinado a la utilizacion por parte de los clientes. Se des- 
arrolla un prototipo del sistema para ayudar a los desarrolladores de software y a los clientes 
a comprender que se debe implementar. Sin embargo, algunas veces se utiliza la expresion 
prototipado evolutivo como sinonimo del desarrollo de software incremental. El prototipo no 
se descarta sino que se desarrolla para cumplir los requerimientos del usuario. 

La Figura 17.2 muestra que el desarrollo y el prototipado incremental tienen objetivos di- 
ferentes: 

1 . El objetivo del desarrollo incremental es entregar a los usuarios finales un sistema fun- 
cional. Esto significa que normalmente debe comenzar con los requerimientos del 
usuario que mejor se comprendan y que tengan la prioridad mas alta. Los requeri- 
mientos inciertos y de prioridad mas baja se implementan cuando sean requeridos por 
los usuarios. 

2. El objetivo del prototipado desechable es validaru obtener los requerimientos del sis- 
tema. Debe comenzar con aquellos requerimientos que no se comprendan bien ya que 
requiere saber mas de ellos. Puede no necesitar nunca prototipar los requerimientos 
sencillos. 

Otra diferencia importante entre estos enfoques esta en la gestion de la calidad de los sis- 
temas. Los prototipos desechables tienen un periodo de vida muy corto. Debe ser posible cam- 
biarlos rapidamente durante el desarrollo, pero no se requiere mantenimiento a largo plazo. 
En dicho prototipo se puede permitir un rendimiento pobre y una baja fiabilidad siempre y 
cuando ayude a entender los requerimientos. 

Por el contrario, los sistemas desarrollados incrementalmente en que las versiones inicia- 
les evolucionan a un sistema final se deben desarrollar con los mismos estandares de calidad 
de la organizacion que cualquier otro software. Deben tener una estructura robusta para que 
se les pueda dar mantenimiento durante muchos aflos. Deben ser fiables y eficientes, y deben 
estaracordes con los estandares organizacionales apropiados. 



17.1 Metodos agiles 

En los aflos 80 y principios de los 90, existia una opinion general de que la mejor forma de 
obtener un mejor software era a traves de una planificacion cuidadosa del proyecto, una ga- 
rantia de calidad formalizada, la utilizacion de metodos de analisis y diseflo soportados por 
herramientas CASE, y procesos de desarrollo de software controlados y rigurosos. Esta opi- 
nion provenia, fundamentalmente, de la comunidad de ingenieros de software implicada en 
el desarrollo de grandes sistemas software de larga vida que normalmente se componian de 
un gran numero de programas individuales. 



Figura 17.2 
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Algunos o la totalidad de estos programas eran a menudo sistemas criticos, como se indi- 
co en el Capitulo 3. Este software era desarrollado por grandes equipos que a veces trabaja- 
ban para compafiias diferentes. A menudo estaban dispersos geograficamente y trabajaban en 
el software durante largos periodos de tiempo. Un ejemplo de este tipo de software son los 
sistemas de control de un avion moderno, en los cuales pueden transcurrir hasta 10 afios des- 
de la especificacion inicial hasta lautilizacion. Estos enfoques, algunos de los cuales trato en 
este libro, implican una importante sobrecarga de trabajo en cuanto a la planificacion, diseno 
y documentaciondel sistema. Este esfuerzo adicional sejustificacuando setienequecoordi- 
nar el trabajo de multiples equipos de desarrollo, cuando el sistema es un sistema critico y 
cuando muchas personas diferentes estaran involucradas en el mantenimiento del software du- 
rante su vida. 

Sin embargo, cuando este enfoque «pesado» de desarrollo basado en la planificacion 
fue aplicado a sistemas de negocio pequenos y de tamano medio, el esfuerzo invertido 
era tan grande que algunas veces dominaba el proceso de desarrollo del software. Se pasaba 
mas tiempo pensando en como se debia desarrollar el sistema que en programar el desarro- 
llo y las pruebas. Cuando cambiaban los requerimientos, se hacia esencial rehacer el tra- 
bajo, y al menos en principio, la especificacion y el diseno tenian que cambiar con el 
programa. 

El descontento con estos enfoques pesados condujo a varios desarrolladores de software 
en los afios 90 a proponer nuevos metodos agiles. Estos permitieron a los equipos de des- 
arrollo centrarse en el software mismo en vez de en su diseno y documentacion. Los metodos 
agiles umversalmente dependen de un enfoque iterativo para la especificacion, desarrollo y 
entrega del software, y principalmente fueron disenados para apoyar al desarrollo de aplica- 
ciones de negocio donde los requerimientos del sistema normalmente cambiaban rapidamen- 
te durante el proceso de desarrollo. Estan pensados para entregar software funcional de for- 
ma rapida a los clientes, quienes pueden entonces proponer que se incluyan en iteraciones 
posteriores del sistema nuevos requerimientos o cambios en los mismos. 

Probablemente el metodo agil mas conocido es la programacion extrema (Beck, 1999; 
Beck, 2000), que se describe posteriormente en este capitulo. Sin embargo, otros enfoques 
agiles son Serum (Schwabery Beedle, 2001), Cristal (Cockburn, 2001), Desarrollo de Sof- 
ware Adaptable (Highsmith, 2000), DSDM (Stapleton, 1997) y Desarrollo Dirigido por Ca- 
racteristicas (Palmer y Felsing, 2002). El exito de estos metodos hallevadoaunaciertainte- 
gracion con metodos de desarrollo mas tradicionales basados en el modelado de sistemas, 
dando por resultado la nocion de modelado agil (Ambler y Jeffries, 2002) y las instanciacio- 
nes agiles del Proceso Unificado de Rational (Larman, 2002). 

Aunque todos estos metodos agiles se basan en la nocion de desarrollo y entrega incre- 
mentales, proponen procesos diferentes para alcanzarla. Sin embargo, comparten un conjun- 
to de principios y, por lo tanto, tienen mucho en comun. En la Figura 17.3 se muestran estos 
principios. 

Los partidarios de los metodos agiles han sido evangelicos en la promocion de su uso y han 
tendido a pasar por alto sus deficiencias. Esto ha provocado una respuesta igualmente radi- 
cal, la cual, exagera los problemas de este enfoque (Stephens y Rosenberg, 2003). Criticos 
mas razonables como DeMarco y Boehm (DeMarco y Boehm, 2002) resaltan tanto las ven- 
tajas como las desventajas de los metodos agiles. Proponen que un enfoque hibrido en el cual 
los metodos agiles incorporen algunas tecnicas del desarrollo basado en la planificacion pue- 
de ser lo mejor a largo plazo. 

En la practica, sin embargo, los principios subyacentes a los metodos agiles son a veces 
dificiles de realizar: 



17.1 • Metodos agiles 363 




Partiripadon del cBente 



Los dientes deben estar nierte m ente implicados en todo el 
pnxeso de desarrollo. Su papel es propordonar y priorizar 
nuevos lequerimientos del sistema y evaiuar las iteradones del 

si sterna. 



Entrega incremental 



El software se desarrolla en incrementos, donde el cfiente 
espedfka Sos requerimientos a indutr en cada incremento. 



Persona* no procesos 



Se deben reconooer y explotar las habHidades del equipo de 
desarrollo. Se les debe dejar desarroNar sus propias formas de 
trabajar, sin procesos formates, a ks miembros del equipo. 



Aceptar el cambio 



Se debe con tar con que los requerirraentos del sistema cambian, 
por k> que el sistema se disefta para dar cabtda a estos cambios. 



Figura 17.3 

Los principios de los 

metodos agiles. 



Mantener la simplicidad 



Se deben centrar en la simplicidad tanto en el software a 
desarrollar como en el proceso de desarrollo. Donde sea posible, 
se trabaja activarrtente para eSmmar la oomplejkbd del sistema. 



1. Si bien la idea de la participacion del cliente en el proceso de desarrollo es atractiva, 
su exito depende de tener un cliente que este dispuesto y pueda pasar tiempo con el 
equipo de desarrollo y que pueda representar a todos los stakeholders del sistema. Fre- 
cuentemente, los representantes de los clientes estan sometidos a otras presiones y no 
pueden participar plenamente en el desarrollo del software. 

2. Los miembros individuales del equipo pueden no tener la personalidad apropiada para 
la participacion intensa que es tipica de los metodos agiles. Por lo tanto, es posible que 
no se relacionen adecuadamente con los otros miembros del equipo. 

3. Priorizar los cambios puede ser extremadamente dificil, especialmente en sistemas en 
lo que existen muchos stakeholders. Por lo general, cada stakeholders proporciona 
prioridades distintas a diferentes cambios. 

4. Mantener la simplicidad requiere un trabajo extra. Bajo presion por las agendas de en- 
tregas, los miembros del equipo pueden no tener tiempo de llevaracabo las simplifi- 
caciones deseables del sistema. 

Otro problema no tecnico, el cual es un problema general con el desarrollo y entrega in- 
crementales, ocurrecuando los clientes del sistema utilizan una organizacion externa para el 
desarrollo del sistema. Como se explico en el Capitulo 6, normalmente el documento de re- 
querimientos del software es parte del contrato entre el cliente y el proveedor. Puesto que la 
especificacion incremental es inherente a los metodos agiles, redactar contratos para este tipo 
de desarrollo puede ser dificil. 

Por consiguiente, los metodos agiles tienen que depender de contratos donde el cliente 
paga por el tiempo necesario para el desarrollo del sistema en vez de por el desarrollo de un 
conjunto de requerimientos especifico. Siempre y cuando vaya todo bien, esto beneficia tan- 
to al cliente como al desarrollados Sin embargo, si surgen problemas puede haber disputas 
sobre quien es el culpable y quien debe pagar por el tiempo extra y recursos necesarios para 
resolver los problemas. 

Todos los metodos tienen limites, y los metodos agiles son solo apropiados para algunos 
tipos de desarrollo de sistemas. Son los mas idoneos para el desarrollo de sistemas de nego- 
cio pequenos y de tamano medio y para el desarrollo de productos para ordenadores perso- 
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nales. No son adecuados para el desarrollo de sistemas a gran escala con equipos de desarro- 
llo ubicados en diferentes lugares y donde puedan habercomplejas interacciones con otros sis- 
temas hardware o software. No se deben utilizar los metodos agiles para el desarrollo de sis- 
temas criticos en los que es necesario un analisis detallado de todos los requerimientos del 
sistema para comprender sus implicaciones de seguridad o proteccion. 

17.2 Programacion extrema 

La Programacion Extrema (XP) es posiblemente el metodo agil mas conocido y ampliamen- 
te utilizado. El nombre fue acunadoporBeck (Beck, 2000) debido a que el enfoque foe desa- 
rrollado utilizando buenas practicas reconocidas, como el desarrollo iterativo, y con la parti- 
cipacion del cliente en niveles «extremos». 

En la programacion extrema, todos los requerimientos se expresan como escenarios (11a- 
mados historias de usuario), los cuales se implementan directamente como una serie de tareas. 
Los programadores trabajan en parejas y desarrollan pruebas para cada tarea antes de escri- 
bir el codigo. Todas las pruebas se deben ejecutar satisfactoriamente cuando el codigo nuevo 
se integre al sistema. Existe un pequeno espacio de tiempo entre las entregas del sistema. La 
Figura 17.4 ilustra el proceso de la XP para producir un incremento del sistema que se esta 
desarrollando. 

La programacion extrema implica varias practicas, resumidas en la Figura 17.5, que se 
ajustan a los principios de los metodos agiles: 

1. El desarrollo incremental se lleva a cabo traves de entregas del sistemapequenasy fre- 
cuentes y por medio de un enfoque para la descripcion de requerimientos basado en 
las historias de cliente o escenarios que pueden ser la base para el proceso de planifi- 
cacion. 

2. La participacion del cliente se lleva a cabo a traves del compromiso a tiempo completo 
del cliente en el equipo de desarrollo. Los representantes de los clientes participan en 
el desarrollo y son los responsables de definir las pruebas de aceptacion del sistema. 

3 . El interes en las personas, en vez de en los procesos, se lleva a cabo a traves de la pro- 
gramacion en parejas, la propiedad colectiva del codigo del sistema, y un proceso de 
desarrollo sostenible que no implique excesivas jornadas de trabajo. 

4. El cambio se lleva a cabo a traves de las entregas regulares del sistema, un desarrollo 
previamente probado y la integracion continua. 

5. El mantenimiento de la simplicidad se lleva a cabo a traves de la refactorizacion cons- 
tante para mejorar lacalidad del codigo y la utilizacion de disenos sencillos que no pre- 
ven cambios futuros en el sistema. 
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Principio o practica Descripcidn 



Pianificaddn 
incremental 



Entregas pequenas 



Los requerimientos se registrar! en tarjetas de historias y. las 
historias a incluir en una entrega se determinan segun el tiempo 
disponibte y su prioridad relativa. Los desarrotladores dwiden estas 
Historias en <Tareas> de desarroHo. Veanse las Figuras 17.6 y 177. 

El mfnimo conjunto util de fundonafidad que propordone valor de 
negocio se desarrolla primero. Las entregas del sistema son 
frecuentes e incrementalmente anaden funcionalidad a la prim era 
entrega. 



Disefto sendllo Sdlo se Neva a cabo el diseno necesario para cumpKr los 

requerimientos actuates. 



Figure 17.5 
Practices de la 
programacion 
extrema. 
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Ctiente presente 



Se utiHza un sistema de pruebas de unidad automatizado para 
escribir pruebas para nuevas funckmalidades antes de que estas se 
implemented 

Se espera que todos los desarrolladores refactoricen el codigo 
continuamente tan pronto como encuetttren posiWes mejoras en 
el codigo. Esto conserva el codigo sendllo y marrteniWe. 

Los desarrolladores trabajan en parejas, verificando cada uno el 
trabajo del otro y propordonando la ayuda necesaria para hacer 
siempre un buen trabajo. 

Las parejas de desarrolladores trabajan en todas las cireas del 
sistema, de modo que no desarroilen islas de conodmientos y 
todos los desarrolladores posean todo el codigo. Cualquiera puede 
cambiar cualquier cosa. 



En cuanto acaba el trabajo en una tarea, se 
entero. Despues de la integradon, se deben 
las pruebas de unidad. 



en el sistema 
al sistema todas 



No se consideran aceptables grandes cantidades de horas extras, 
ya que a menudo el efecto que Henen es que se reduce la calidad 
del codigo y la productividad a medio plazo. 

Debe estar disponible al equipo de la XP un representante de tos 
usuarios finales del sistema (el diente) a tiempo compteto. En un 
proceso de la programacion extrema, el cfiente es miembro del 
equipo de desarrollo y es responsable de formutar al equipo los 
requerimientos del sistema para su tmpleinentadon. 



En un proceso de la XP, los clientes estan fiiertemente implicados en la especificacion y 
establecimiento de prioridades de los requerimientos del sistema. Los requerimientos no se 
especifican como una listade funciones requeridas del sistema. Mas bien, los clientes del sis- 
tema son parte del equipo de desarrollo y discuten escenarios con otros miembros del equi- 
po. Desarrollan conjuntamente una «tarjeta de historias» (story cara) que recoge las necesi- 
dades del cliente. El equipo de desarrollo intentara entonces implementar ese escenario en una 
entrega futura del software. En la Figura 17.6 se ilustra un ejemplo de una tarjeta de historia 
para el sistema L IB SY S , basada en un escenario del Capitulo 7. 
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Descarga e impresidn de un articulo 

En primer lugar, seleccione el articulo que desea de una list a visualizada. 
Tiene entonces que decide ai sistema cdmo lo pagar£ -se puede hacer 
a traves de una suscripcibn, una cuenta de empresa o mediante una 
tarjeta de credito. 

Despues de esto, obtiene un formulario de derechos de autor del sistema 
para que lo rellene. Cuando lo haya enviado, se descarga el articulo en 
su computadora. 

Elija una impresora y se imprimis una copia del articulo. Le dice al 
sistema que la impresion se ha realizado correctamente. 

Si es un articulo de s6lo impresion, no puede guardar la versibn en PDF, 
por lo que automtticamente se elimina de su computadora. 



Una vez que se han desarrollado las tarjetas de historias, el equipo de desarrollo las divi- 
de en tareas y estima el esfuerzo y recursos requeridos para su implementacion. El cliente es- 
tablece entonces la prioridad de las historias a implementar, eligiendo aquellas historias que 
pueden ser utilizadas inmediatamente para entregar un apoyo util al negocio. Por supuesto, 
cuando los requerimientos cambian, las historias sin implementar tambien cambian o se pue- 
den descartar. Si se requieren cambios en un sistema que ya se ha entregado, se desarrollan 
nuevas tarjetas de historias y, de nuevo, el cliente decide si estos cambios tienen prioridad so- 
bre nuevas funcionalidades. 

La programacion extrema adopta un enfoque «extremo» para el desarrollo iterativo. Se 
pueden construir varias veces al dia nuevas versiones del software y los incrementos se en- 
tregan al cliente cada dos meses aproximadamente. Cuando un programador construye el sis- 
tema para crear una version nueva, debe ejecutar todas las pruebas automatizadas existentes 
ademas de las pruebas para las funcionalidades nuevas. El nuevo software generado solamente 
se acepta si se ejecutan satisfactoriamente todas las pruebas. 

Un precepto fundamental de la ingenieria del software tradicional es que se debe disenar 
para el cambio. Esto es, hay que prever los cambios futuros en el software y disenar este de 
forma que tales cambios se puedan implementar facilmente. Sin embargo, la programacion 
extrema ha descartado este principio partiendo del hecho de que disenar para el cambio es a 
menudo un esfuerzo inutil. Con frecuencia los cambios previstos nunca se materializan y re- 
almente se efectuan peticiones de cambios completamente diferentes. 

El problema con la implementacion de cambios imprevistos es que tienden a degradar la 
estructura del software, por lo que los cambios se hacen cada vez mas dificiles de implemen- 
tar. La programacion extrema aborda este problema sugiriendo que se debe refactorizarcons- 
tantemente el software. Esto significa que el equipo de programacion busca posibles mejoras 
del software y las implementa inmediatamente. Por lo tanto, el software siempre debe ser fa- 
cil de entendery cambiar cuando se implementen nuevas historias. 

17.2.1 Pruebas en XP 

Como se ha indicado en la introduccion de este capitulo, una de las diferencias importantes 
entre el desarrollo iterativo y el desarrollo basado en la planificacion es la forma de probar el 
sistema. Con el desarrollo iterativo, noexisteunaespecificaciondel sistema que pueda ser uti- 
lizada por un equipo de pruebas externo para desarrollar las pruebas del sistema. Por consi- 
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documentos. 
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guiente, algunos enfoques para el desarrollo iterativo tienen un proceso de pruebas muy 
informal. 

Para evitar algunos de los problemas de las pruebas y de la validacion del sistema, XP pone 
mas enfasis en el proceso de pruebas que otros metodos agiles. Las pruebas del sistema son 
fundamentales en XP, en la que se ha desarrollado un enfoque que reduce la probabilidad de 
producir nuevos incrementos del sistema que introduzcan errores en el software existente. 

Las caracteristicas clave de las pruebas en XP son: 

1. Desarrollo previamente probado. 

2. Desarrollo de pruebas incremental a partir de los escenarios. 

3. Participacion del usuario en el desarrollo de las pruebas y en la validacion, 

4. El uso de bancos de pruebas automatizados. 

El desarrollo previamente probado es una de las innovaciones mas importantes en XP. Al 
escribir primero las pruebas se define implicitamente tanto una interfaz como una especifica- 
cion del funcionamiento para la funcionalidad a desarrollar. Se reducen los problemas en los 
requerimientos y las confusiones de la interfaz. Se puede adoptar este enfoque en cualquier 
proceso en el que exista una relacion clara entre un requerimiento del sistema y el codigo que 
implementa ese requerimiento. En XP, siempre puede verse este vinculo debido a que las tar- 
jetas de historias que representan los requerimientos se dividen en tareas, y las tareas son las 
unidades principales de implementacion. 

Como se ha senalado, los requerimientos de usuario en XP se expresan como escenarios o 
historias y el usuario establece las prioridades de estos para su desarrollo. El equipo de des- 
arrollo evaluacada escenarioy lo divide en tareas. Cada tarearepresentaunacaracteristicadis- 
tinta del sistema y se puede disefiar entonces una prueba de unidad para esa tarea. Por ejem- 
plo, en la Figura 17.7 se muestran algunas de las tarjetas de tareas (task cards) desarrolladas 
a partir de la tarjeta de historia para la descarga de documentos (Figura 17.6). 

Cada tarea genera una o mas pruebas de unidad que verifican la implementacion descrita en 
esa tarea. Por ejemplo, la Figura 17.8 es una descripcion abreviada de un caso de pruebas que se 
ha desarrollado para comprobar que se ha implementado un numero de tarjeta de credito valido . 

El papel del cliente en el proceso de pruebas es ayudar a desarrollar las pruebas de acep- 
tacion para las historias que se tienen que implementar en la siguiente entrega del sistema. 
Como se explica en el Capitulo 23, las pruebas de aceptacion son el proceso en el que se 
prueba el sistema utilizando datos del cliente para verificar que cumple sus necesidades reales. 



Figura 17.7 Tarjetas 
de tareas para la 
descarga de 
documentos. 



Tarea 1 : Implementar el flujo de trabajo principal 



Tarea 2: ImpiemerrUr catalogo y selecdon de articulos 



Tarea 3: Implementar formas de pago 



El pago se puede efectuar de 3 formas diferentes. El usuario 
selecciona de que forma desea pagar. Si el usuario tiene una 
suscripcion a la biblioteca, puede introducir la clave de suscriptor, 
la cual debe ser verificada por el sistema. De forma alternativa, 
puede introducir un numero de cuenta organizational. Si es 
valido, se a not a un cargo en la cuenta por el importe del artfculo. 
Finalmente, puede introducir un numero de tarjeta de credito 
de 16 dlgitos y la fecha en la que caduca. Se debe comprobar la 
validez de estos datos y, si son validos, se anota un cargo en la 
cuenta de la tarjeta de credito. 



368 CAPITULO 17 • Desarrollo rapido de software 



Prueba 4: Prueba de la validez de la tarjeta de credito 
Entrada: 

Una cadena que represents el numero de tarjeta de credito y dos enteros que 

representan el mes y el ano de la caducidad de la tarjeta. 

Pruebas: 

Comprobar que todos los bytes de la cadena son digrtos. 

Comprobar que el mes se encuentra entre 1 y 12 y que el ano es mayor o igua! 

que el ano actual. 

Utilizando los 4 primeros dlgitos del numero de tarjeta de credito, comprobar 
que el emisor de la tarjeta es valido consultando la tabla de emisores de 
tarjetas. Comprobar la validez de la tarjeta de credito enviando el numero 
de tarjeta y la fecha en la que caduca el emisor de la tarjeta. 
Sallda: 

OK o un mensaje de error indicando que la tarjeta no es vdlida. 



EnXP, las pruebas de aceptacion, como el desarrollo, son incrementales. Para esta historia 
en particular, la prueba de aceptacion implicari a seleccionar varios documentos, pagarlos de 
diferentes formas e imprimirlos en impresoras distintas. En la practica, probablemente se 
desarrollaria una serie de praebas de aceptacion en vez de una unica prueba. 

El desarrollo previamente probado y el uso de bancos de pruebas automatizados son las 
principales virtudes del enfoque de la XP . En vez de escribir el codigo del programa y luego 
las pruebas de ese codigo, el desarrollo previamente probado significa que las pruebas se es- 
criben antes que el codigo. Fundamentalmente, las pruebas se escriben como un componen- 
te ejecutable antes de que se implemente la tarea. Una vez que se ha implementado el soft- 
ware, se pueden ejecutar las pruebas inmediatamente. Este componente de pruebas debe ser 
unaaplicacion independiente, debe simularel enviode la entrada a probary debe verificarque 
el resultado cumple la especificacion de salida. El banco de pruebas automatizado es un sis- 
tema que envia a ejecucion estas pruebas automatizadas. 

Con el desarrollo previamente probado, siempre hay un conjunto de pruebas que se pue- 
den ejecutar facilmente y de forma rapida. Esto significa que siempre que se afiada cualquier 
funcionalidad al sistema, se pueden ejecutar las pruebas y detectar inmediatamente los pro- 
blemas que el codigo nuevo haya introducido. 

En el desarrollo previamente probado, las personas encargadas de jmplementar las tareas 
tienen que comprender perfectamente la especificacion, de modo que puedan escribir las 
pruebas del sistema. Esto significa que se tienen que clarificar las ambigiiedadesy omisiones 
en la especificacion antes de que empiece la implementacion. Ademas, esto tambien evita el 
problema del «retraso de las pruebas», en el que, debido a que los desarroliadores del siste- 
ma trabajan a un ritmo mas elevado que los probadores, cada vez se adelanta mas la imple- 
mentacion sobre las pruebas y hay una tendencia a saltarse las pruebas para poder mantener 
la agenda establecida. 

Sin embargo, el desarrollo previamente probado no siempre funciona segun lo previsto. 
Los programadores prefieren la programacion a las pruebas y algunas veces escriben pruebas 
incompletas que no comprueban las situaciones excepcionales. Ademas, puede serdificil es- 
cribir algunas pruebas. Por ejemplo, en una interfaz de usuario compleja, con frecuencia es 
dificil escribir las pruebas de unidad para el codigo que implementa la «vista 16gica» y el flu- 
jo de trabajo entre las pantallas. Por ultimo, es dificil juzgar la completitud de un conjunto de 
pruebas. Aunque se pueda tener una gran cantidad de pruebas del sistema, ese conjunto de 
pruebas puede no proporcionar una cobertura completa. Es posible que no se ejecuten partes 
cruciales del sistema y, por lo tanto, se queden sin probar. 
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Contar con el cliente para el apoyo al desarrollo de las pruebas de aceptacion es a veces un 
problema serio en elproceso de pruebas de laXP. Las personas que adoptan elpapel de clien- 
te tienen muy poco tiempo disponible y es posible que no puedan trabajar a tiempo comple- 
te con el equipo de desarrollo. El cliente puede pensar que proporcionar los requerimientos 
es contribucion suficiente y puede ser reacio a participar en el proceso de pruebas. 

17.2.2 Programacion en parejas 

Otra practica innovadora que se ha introducido es que los programadores trabajan en parejas 
para desarrollar el software. De hecho, se sientanjuntos en la misma estacion de trabajo para 
desarrollar el software. El desarrollo no siempre implica la misma pareja de personas traba- 
jando juntas. Mas bien, la idea es que las parejas se creen de forma dinamica para que todos 
los miembros del equipo puedan trabajar con los otros miembros en una pareja de programa- 
cion durante el proceso de desarrollo. 

El uso de la programacion en parejas tiene varias ventajas: 

1 . Apoya la idea de la propiedad y responsabilidad comunes del sistema. Esto refleja la 
idea de Weinberg de la programacion sin ego (Weinberg, 1971), en la que el equipo 
como un todo es dueflo del software y las personas individuales no tienen la culpa de 
los problemas con el codigo. En cambio, el equipo tiene una responsabilidad colecti- 
va para resolver estos problemas. 

2. Actiia como un proceso de revision informal ya que cada linea de codigo es vista por 
al menos dos personas. Las inspecciones y revisiones del codigo (tratadas en el Capi- 
tulo 22) consiguen descubrir un alto porcentaje de errores del software. Sin embargo, 
requiere mucho tiempo organizarias y, por lo general, generan retrasos en el proceso 
de desarrollo. A pesar de que la programacion en parejas es un proceso menos formal 
que probablemente no encuentre tantos errores, es un proceso de inspeccion mucho 
mas economico que las inspecciones formales de programas. 

3. Ayudaen la refactorizacion, lacual es un proceso de mejoradel software. Unprinci- 
pio de la XP es que se debe refactorizar constantemente el software. Es decir, se de- 
ben escribir nuevamente partes del codigo para mejorar su claridad y estructura. El 
problema para implementar esto en un entorno de desarrollo normal es que es un es- 
fuerzo que se gasta para obtener un beneficio a largo plazo, y se puede juzgar a una 
persona que practique la refactorizacion como menos eficiente que otra que simple- 
mente realice el desarrollo del codigo . Cuando se utiliza la programacion en parejas y 
lapropiedad colectiva, otros se benefician inmediatamente con la refactorizacion, por 
lo que probablemente apoyaran el proceso. 

Podria pensarse que la programacion en parejas es menos eficiente que la programacion 
individual y que una pareja de desarroliadores produciria, como mucho, la mitad del codigo 
que dos personas trabajando individualmente. Sin embargo, diversos estudios sobre desarro- 
llos que utilizan XP no confirman esto. Laproductividad del desarrollo con programacion en 
parejas parece ser comparable con la de dos personas trabajando de forma independiente (Wi- 
lliams el al., 2000). Las razones para esto son que las parejas discuten sobre el software an- 
tes de empezar el desarrollo, por lo probablemente tengan menos comienzos en falso y ten- 
gan que rehacer menos trabajo, y que el numero de errores evitados debido a la inspeccion 
informal es tal que se pasa menos tiempo arreglando errores descubiertos durante el proceso 
de pruebas. 
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173 Desarrollo rapido de aplicaciones 

Aunque los metodos agiles como un enfoque para el desarrollo iterativo han recibido una gran 
atencion en los ultimos aflos, los sistemas de negocio se han desarrollado de forma iterativa 
durante muchos aflos utilizando tecnicas de desarrollo rapido de aplicaciones. Las tecnicas de 
desarrollo rapido de aplicaciones (RAD) evolucionaron de los llamados lenguajes de cuarta 
generacion en los aflos 80 y se utilizan para desarrollar aplicaciones con un uso intensivo de 
datos. Por consiguiente, normalmente estan organizadas como un conjunto de herramientas 
que permiten crear datos, buscarlos, visualizarlos y presentarlos en informes. La Figura 17.9 
ilustra una organizacion tipica de un sistema RAD . 

Las herramientas que se incluyen en un entorno RAD son: 

1. Un lenguaje de programacion de bases de dalos, que contiene conocimiento de la es- 
tructura de la base de datos y que incluye las operaciones basicas de manipulacion de 
bases de datos. El lenguaje estandarde programacion de base de datos es SQL (Groff 
etai, 2002). Los comandos SQL se pueden introducir directamente o generarde for- 
ma automatica a partir de formularios rellenados por los usuarios finales. 

2. Un generador de interfaces, que se utiliza para crear formularios de introduccion y vi- 
sual i zacion de datos. 

3. Enlaces a aplicaciones de oficina, como una hoja de calculo para el analisis y mani- 
pulacion de informacion numerica o unprocesador de textos para la creacion de plan- 
tillas de informes. 

4. Un generador de informes, que se utiliza para definir y crear informes a partir de la 
informacion de la base de datos. 

Los sistemas R AD tienen exito debido a que, como se explico en el Capitulo 13, las apli- 
caciones de negocio tienen muchas cosas en comun. Esencialmente, a menudo estas aplica- 
ciones comprenden la actualizacion de una base de datos y la produccion de informes a par- 
tir de la informacion existente en ella. Se utilizan formularios estandar para las entradas y 
salidas. Los sistemas RAD estan dirigidos a laproduccionde aplicaciones interactivas que se 
apoyan la abstraccion de la informacion en una base de datos organizacional, presentandola 
a los usuarios finales en su terminal o estacion de trabajo, y actualizando la base de datos con 
los cambios hechos por los usuarios. 

Muchas de las aplicaciones de negocio se apoyan en formularios estructurados para las en- 
tradas y salidas, por lo que los entornos RAD proporcionan recursos potentes para la defini- 
cion de pantallas y generacion de informes. A menudo, las pantallas se definen como una se- 
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rie de formularios vinculados (en una aplicacion que estudiamos, hubo 137 definiciones de 
formularios), por lo que el sistema de generacion de pantallas debe proporcionar: 

1 . Definition de formularios interactivos que permitan al desarrollador definir los cam- 
pos a visualizar y la manera en que estos deben organizarse. 

2. Vinculacion de los formularios que permitan al desarrollador especificar que ciertas 
entradas provocan la visualizacion de formularios adicionales. 

3. Verification de campos que permitan al desarrollador definir los rangos permitidos 
para los valores de entrada en los campos de los formularios. 

Hoy en dia, muchos entornos RAD permiten el desarrollo de interfaces de bases de datos 
basadas en navegadores web. Dichos entornos permiten el acceso a la base de datos desde 
cualquier lugar a traves de una conexion valida de Internet. Esto reduce los costes de forma- 
cion y de software, y permite a los usuarios externos tener acceso a una base de datos. Sin em- 
bargo, las limitaciones inherentes de los navegadores web y los protocolos de Internet impli- 
can que este enfoque no sea adecuado para sistemas en los que se requieran respuestas 
interactivas muy rapidas. 

Actualmente, la mayoriade los sistemas RAD incluyen herramientas de programacion vi- 
sual que permiten desarrollar sistemas de forma interactiva. En vez de escribir un programa 
secuencial, el desarrollador del sistema manipula iconos graficos que representan funciones, 
datos o componentes de interfaces de usuario, y asocia el procesamiento de secuencias de co- 
mandos con estos iconos. Se genera automaticamente un programa ejecutable a partir de la 
representacion visual del sistema. 

Los sistemas de desarrollo visual, como Visual Basic, permiten este enfoque basado en la 
reutilizacion para el desarrollo de aplicaciones. Los programadores de estas construyen el sis- 
tema de forma interactiva definiendo la interfaz en terminos de pantallas, campos, botones y 
menus. A estos, se les asigna un nombre y se asocia el procesamiento de secuencias de co- 
mandos con partes individuales de la interfaz (por ejemplo, un boton denominado Simular). 
Estas secuencias de comandos pueden hacer llamadas a componentes reutilizables, a codigo 
de proposito especial o a una mezcla de ambos. 

Este enfoque se ilustra en la Figura 17.10, la cual muestra una pantalla de aplicacion que 
incluye menus en la parte superior, campos de entrada (los campos blancos a la izquierda de 
la pantalla), campos de salida (el campo gris a la izquierda de la pantalla) y botones (los rec- 
tangulos redondeados a la derecha de la pantalla). Cuando el sistema de programacion visual 
ubica en la pantalla estas entidades, el desarrollador define que componentes reutilizables se 
deben asociar con ellos o escribe un fragmento de programa para llevar a cabo el procesa- 
miento requerido. Tambien se muestran en laFigura 17.10 los componentes asociados con al- 
gunos de los elementos de la pantalla. 

Visual Basic es un ejemplo muy sofisticado de un lenguaje de creacion de secuencias de 
comandos (Ousterhout, 1998). Estos son lenguajes de alto nivel sin tipos disenados que ayu- 
dan a integrar componentes para crear sistemas. Uno de los primeros lenguajes de este tipo 
fue el shell deUnix (Bourne, 1978; Gordon y Bieman, 1995); desde su desarrollo, se hancre- 
ado varios lenguajes de creacion de secuencias de comandos mas potentes (Ousterhout, 1994; 
Lutz, 1996; Wall etal., 1996). Estos lenguajes incluyen estructuras de control yjuegos de he- 
rramientas graficas que, como ilustra Ousterhout (Ousterhout, 1998), pueden reducir radical- 
mente el tiempo requerido para el desarrollo del sistema. 

Este enfoque para el desarrollo de sistemas permite el desarrollo rapido de aplicaciones re- 
lativamente sencillas que pueden ser construidas por un equipo pequeno de personas. Es mas 
dificil de organizar para sistemas mas grandes que deben ser desarrollados por equipos con 
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Figura 17.10 Programacion visual con reutilizacion. 



un mayor numero de personas. No existe una arquitectura explicita del sistema y a menudo 
existen dependencias complejas entre las partes del sistema, lo que puede causar problemas 
cuando se requieran cambios. Ademas, debido a que los lenguajes de creacion de secuencias 
de comandos se limitan a un conjunto especifico de objetos en interaccion, puede serdificil 
implementar interfaces de usuario no estandares. 

El desarrollo visual es un enfoque a RAD que utiliza la integration de componentes soft- 
ware reulilizables de grano fino. Un enfoque alternativo basado en la reutilizacion reutiliza 
«componentes» que son sistemas de aplicaciones completos. Este se denomina a veces des- 
arrollo basado en COTS, donde COTS (Commercial Off-the-Shelf) significa que las aplica- 
ciones yaestan disponibles. Por ejemplo, si un sistema requiere las funcionalidadesdeunpro- 
cesador de textos, podria utilizar un procesador de textos estandar como Microsoft Word. En 
el Capitulo 18 se estudia el desarrollo basado en COTS desde la perspectiva de la reutiliza- 
cion. 

Para ilustrarel tipo de aplicacion que se podria desarrollar utilizando un enfoque basado 
en COTS, consideremos el proceso de gestion de requerimientos descrito en el Capitulo 7. Un 
sistema de apoyo a dicha gestion necesita una forma de capturar y almacenar los requeri- 
mientos, producir los informes, descubrir las relaciones entre los requerimientos y gestionar 
estas relaciones como tablas de rastreo. En un enfoque basado en COTS, se podria construir 
un prototipo vinculando una base de datos (para almacenar los requerimientos), un procesa- 
dor de textos (para capturar los requerimientos y los formatos de los informes), una hoja de 
calculo (para gestionar las tablas de rastreo) y codigo escrito especificamente para encontrar 
las relaciones entre los requerimientos. 

El desarrollo basado en COTS da acceso al desarrollador a toda la funcionalidad de una 
aplicacion. Si esta tambien proporciona recursos de creacion de secuencias de comandos o de 
ajuste (por ejemplo, macros de Excel), estos se pueden utilizar para desarrollar cierto tipo de 
funcionalidad de la aplicacion. Para comprender este enfoque de desarrollo de aplicaciones 
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Figura 17.11 
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es de utilidad una metafora de composicion de documentos. Los datos procesados por el sis- 
tema se pueden organizar en un documento compuesto que actua como un contenedor de va- 
rios objetos. Estos objetos contienen diferentes tipos de datos (como una tabla, un diagrama, 
un formulario) que pueden ser procesados por diferentes aplicaciones. Los objetos se enlazan 
y se clasifican para que al acceder a un objeto se inicie la aplicacion asociada. 

La Figura 17.1 1 ilustra un sistema de aplicaciones formado por un documento compuesto 
que incluye elementos de texto, de hojas de calculo y archivos de sonido. Los elementos de 
texto son procesados por el procesador de textos; las tablas, por la aplicacion de hojas de cal- 
culo, y los archivos de sonido, por el reproductor de audio. Cuando un usuario del sistema ac- 
cede a un objeto de un tipo particular, se llama a la aplicacion asociada para proporcionar la 
funcionalidad al usuario. Por ejemplo, cuando se accede a objetos de tipo sonido, se llama al 
reproductor de audio para procesarlos. 

La principal ventaja de este enfoque es que mucha de la funcionalidad de la aplicacion se 
puede implementar rapidamente a un coste muy bajo. Los usuarios que ya esten familiariza- 
dos con las aplicaciones que componen el sistema no tendran que aprender como utilizar las 
nuevas caracteristicas. Sin embargo, si no saben como utilizar las aplicaciones, el aprendiza- 
je puede serdificil, especialmente si estan confundidos con la funcionalidad innecesaria de la 
aplicacion. Puede haber tambien problemas de rendimiento en la aplicacion debido a la ne- 
cesidad de cambiarde una aplicacion del sistema a otra. Este esfuerzo adicional para realizar 
el cambio entre aplicaciones depende de la ayuda que proporcione el sistema operativo. 



17.4 Prototipado del software 

Como se ha indicado en la introduccion de este capitulo, existen algunas circunstancias en las 
que. por razones practicas o contractuales, no se puede utilizar un proceso de entrega del soft- 
ware incremental. En esas situaciones, se completaunadeclaracionde los requerimientos del 
sistema y es utilizada por el equipo de desarrollo como la base para el software del sistema. 
Como se ha explicado, se pueden conseguir algunos de los beneficios de un proceso de des- 
arrollo incremental creando un prototipo del software. Este enfoque se denomina a veces pro- 
totipado desechable debido a que el prototipo no es entregado al cliente o mantenido por el 
desarroi lador. 

Un prototipo es una version inicial de un sistema software que se utiliza para demostrar 
conceptos, probar opciones de diseno y, en general, informarse mas del problema y sus posi- 
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bles soluciones. El desarrollo rapido e iterativo del prototipo es esencial, de modo que los cos- 
tes sean controlados y los stakeholders del sistema puedan experimentar con el prototipo en 
las primeras etapas del proceso del software. 

Un prototipo del software se puede utilizarde varias maneras en un proceso de desarrollo 
de software: 

1. En el proceso de ingenieria de requerimientos, un prototipo puede ayudar en la ob- 
tencion y validacion de los requerimientos del sistema. 

2. En el proceso de diseno del sistema, se puede utilizarun prototipo para explorar solu- 
ciones software particulares y para apoyar al diseno de las interfaces de usuario. 

3. En el proceso de pruebas, se puede utilizar un prototipo para ejecutar praebas back- 
to-back con el sistema que se entregaran al cliente. 

Los prototipos del sistema permiten a los usuarios ver como este apoya su trabajo. Pueden 
adquirir nuevas ideas para los requerimientos y encontrar areas fuertes y debiles en el soft- 
ware. Entonces pueden proponer nuevos requerimientos del sistema. Ademas, a medida que 
se desarrolla el prototipo, puede revelar errores y omisiones en los requerimientos propues- 
tos. Una funcion descrita en una especificacion podria parecer Ml y bien definida. Sin em- 
bargo, cuando la funcion se combina con otras, a menudo los usuarios comprueban que su vi- 
sion inicial fue incorrecta o incompleta. La especificacion del sistema podria modificarse para 
reflejarel cambio en la comprension de los requerimientos. 

Se puede utilizarun prototipo del sistema mientras se este disenando el sistema para lle- 
var a cabo experimentos de diseno con el fin de verificar la viabilidad de un diseno propues- 
to. Por ejemplo, un diseno de una base de datos puede ser prototipado y probado para verifi- 
car que las consultas mas comunes de los usuarios tienen el acceso a los datos mas eficiente. 
El prototipado es tambien una parte fundamental del proceso de diseno de las interfaces de 
usuario. Debido a la naturaleza dinamica de las interfaces de usuario, las descripciones tex- 
tuales y los diagramas no son suficientes para expresar los requerimientos de estas. Por lo tan- 
to, el prototipado rapido con la participacion del usuario final es la linica forma razonable de 
desarrollar interfaces graficas de usuario para sistemas software. 

Un problema importante en las praebas del sistema es la validacion de las praebas, donde 
tiene que comprobarse si los resultados de una praeba son lo que se esperaba. Cuando esta 
disponible un prototipo del sistema, se puede reducir el esfuerzo realizado en la comproba- 
cion de los resultados ejecutando praebas back-to-back (Figura 17.12). Se envian los mismos 
casos de prueba tanto al prototipo como al sistema en praeba. Si ambos dan el mismo resul- 
tado, probablemente el caso de prueba no haya detectado ningun defecto. Si los resultados di- 
fieren, puede significar que hay un defecto en el sistema y se deben investigar las razones de 
la diferencia. 

Por ultimo, ademas de apoyar las actividades del proceso del software, se pueden utilizar 
prototipos a fin de reducir el tiempo requerido para desarrollar la documentacion del usuario 
y para formarlos. Un sistema funcional, aunque limitado, esta disponible de forma rapidapara 
demostrar la viabilidad y utilidad de la aplicacion a la direccion. 

En un estudio de 39 proyectos de prototipado, Gordon y Bieman (Gordon y Bieman, 1995) 
observaron que los beneficios de utilizar el prototipado fueron: 

1. Mejora en lausabilidad del sistema 

2. Una mejor concordancia entre el sistema y las necesidades del usuario 

3. Mejora en la calidad del diseno 

4. Mejora en el mantenimiento 

5. Reduccion en el esfuerzo de desarrollo 
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Su estudio sugiere que las mejoras en la usabilidad y en la definicion de requerimientos 
del usuario debido a la utilizacion de un prototipo no significan necesariamente un incremento 
general en los costes de desarrollo. Por lo general, la construccion de prototipos incrementa 
los costes en las etapas iniciales del proceso del software pero reduce los costes posteriores 
en el proceso de desarrollo. La razon principal de esto es que se evita rehacer el trabajo du- 
rante el desarrollo debido a que los clientes solicitan menos cambios en el sistema. Sin em- 
bargo, Gordon y Bieman observaron que el rendimiento general del sistema algunas veces se 
degrada si se reutiliza codigo ineficiente proveniente del prototipo. 

En la Figura 17.13 se muestra un modelo del proceso para el desarrollo de prototipos. Los 
objetivos de la construccion de estos deben serexplicitos desde el inicio del proceso. Estos 
pueden ser desarrollar un sistema para construir un prototipo de la interfaz de usuario, des- 
arrollar un sistema para validar los requerimientos funcionales del sistema o para demostrar 
la viabilidad de la aplicacion a la direccion. El mismo prototipo no puede cumplir todos los 
objetivos. Si estos no se especifican, la direccion o los usuarios finales pueden mal interpretar 
la funcion del prototipo. En consecuencia, es posible que no obtengan los beneficios que es- 
peran del desarrollo de este. 

La siguiente etapa en el proceso es decidirque incluiry, quizas lo mas importante, que ex- 
cluir del sistema prototipo. Para reducir los costes de la construccion del prototipo y acelerar 
la agenda de entregas, se puede excluir de este cierta funcionalidad. Se puede decidir relajar 
los requerimientos no funcionales, como el tiempo de respuesta y la utilizacion de la memo- 
ria. La gestion y manejo de errores se puede pasar por alto o hacerse de forma rudimentaria, 
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a menos que el objetivo del prototipo sea establecer una interfaz de usuario. Se pueden redu- 
cir los estandares de fiabilidad y calidad de la programacion. 

La etapa final del proceso es la evaluacion del prototipo. En esta se debe prever la forma- 
cion del usuario y se deben utilizar los objetivos del prototipo para obtener un plan de eva- 
luacion. Los usuarios requieren tiempo para acostumbrarse a un nuevo sistema y utilizarlo de 
forma normal. Una vez que lo utilizan, descubren los errores y omisiones en los requeri- 
mientos. 

Un problema general con el desarrollo de un prototipo desechable ejecutable es que el 
modo de utilizarlo puede que no se corresponda con el modo en que se utiliza el sistema fi- 
nal entregado. El probador del prototipo puede no ser el tipico usuario de este. El tiempo de 
formacion durante la evaluacion de! prototipo puede ser insuficiente. Si el prototipo es lento, 
los evaluadores pueden modificar su forma de trabajar y evitar aquellas caracteristicas que ten- 
gan tiempos de respuesta lentos. Si el sistema final tiene mejor tiempo de respuesta, pueden 
utilizarlo de forma diferente. 

Algunas veces, los gerentes presionan a los desarrolladores para que entreguen los proto- 
tipos desechables, especialmente cuando existen retrasos en la entrega de la version final de! 
software. En vez de hacer frente a los retrasos en el proyecto, los gerentes pueden creer que 
entregar un sistema incompleto o de baja calidad es mejor que nada. Sin embargo, normal- 
mente esto no es aconsejable por las siguientes razones: 

1. Puede ser imposible ajustar el prototipo para que cumpla con los requerimientos no 
funcionales que fueron dejados de lado durante su desarrollo, como los de rendimien- 
to, proteccion, robustez y fiabilidad. 

2. El cambio rapido durante el desarrollo significa, inevitablemente, que no se documenta 
el prototipo. La unica especificacion del disefio es el codigo del prototipo. Esto no es 
suficiente para el mantenimiento a largo plazo. 

3. Los cambios hechos durante el desarrollo del prototipo probablemente degradan la es- 
tructura del sistema. Este sera dificil y caro de mantener. 

4. Los estandares de calidad organizacionales normalmente se relajan para el desarrollo 
del prototipo. 

Los prototipos desechables no tienen que ser ejecutables para ser de utilidad en el proce- 
so de ingenieriade requerimientos. Como se explica en el Capitulo 16, las maquetas en papel 
de la interfaz de usuario (Rettig. 1994) pueden ser efectivas para ayudar a los usuarios a per- 
feccionar un disefio de la interfaz y a trabajar a traves de escenarios de utilizacion. Estos son 
muy baratos de desarrollar y se pueden construir en pocos dias. Una extension de esta tecni- 
ca es un prototipo Mago de Oz en el que solo se desarrolla la interfaz de usuario. Los usua- 
rios interactuan con esta interfaz, pero sus peticiones se pasan a una persona que los interpreta 
y muestra la respuesta apropiada. 



PUNTOS CLAVE 



* Al crecer la presion por una entrega rapida del software, se utiliza cada vez mas un enfoque iterativo para et 
desarrollo del software como una tecnica de desarrollo estandar para sistemas pequenosy de tamario medio, 
especialmente en et dominio de los negocios. 
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• Los metodos agiles son metodos de desarrollo iterativo que se centran en la especif icacion. diseno e Imple- 
mentacion del sistema de forma incremental. Implican directamente a tos usuarios en el proceso de desarro- 
llo. Reducir la sobrecarga en cuanto al esfuerzo de desarrollo puede hacer posible un desarrollo del software 
mas rapido. 

• La programacion extrema es un metodo agil conocido que integra unavariedad de buenas practicasde pro- 
gram ac i 6 n , como tas pruebas siste maticas, la continua mejora del software yta part icipacion del die n teen el 
equipo de desarrollo. 

• Un punto fuerte particular de la programacion extrema es el desarrollo de pruebas automatizadas antes de 
que se cree una funcionalidad en un programa. Se deben ejecutar de forma satisfactoria todas las pruebas 
cuando se integra un incremento en un sistema. 

• Et desarrollo rapido deaplicacionesimplica la utilizacionde en tornosde desarrollo que incluyan herramien- 
tas potentes para apoyar laproducciondel sistema. Est as comprenden lenguajes deprogramacionde bases 
de datos, generadores de formularios e informes, y enlaces a aplicaciones de oficina. 

El prototipado desechabte es un proceso de desarrollo iterativo en el que se utiliza un sistema prototipo para 
explorar los requerimientos ylasopcionesdediseno. Este prototipo noestadestinadoparasuutilizacionpor 
parte de los clientes del sistema. 

• Cuando se implementa un prototipo desechabte, primero se tienen que desarrollar las partes del sistema que 
menos se comprenden; porel contrario, en un enfoque de desarrollo incremental, se empieza desarrollando 
tas partes del sistema que mejor se comprenden. 



LECTURAS ADICIONALES 

Extreme Programming Explained. Este foe el primer libro sobre XP y es todavia, quizas, el que mas merece la pena 
leer. Explica el enfoque desde la perspectiva de uno de sus inventores, y llega muy claramente su entusiasmo. (Kent 
Beck, 2000, Addison-Wesley.) 

«Get ready for agile methods, with care». Una seria critica de los metodos agiles que analiza sus puntos fuertes y 
debiles, redactada por ingenieros de software tremendamente experimentados. (B. Boehm, IEEE Computer, enero 
de 2002.) 

«Scripting: Higher-level programming for the 2ist century». Una vision general de tos lenguajes de creacion de se- 
cuencias de comandos por el inventor de Tcl/Tk, quien describe las ventajas de este enfoque para el desarrollo ra- 
pido de aplicaciones. O- K. Ousterhout, IEEE Computer, marzo de 1998.) 

DSDM: Dynamic Systems Development Meted. Una descripcion de un enfoque para el desarrollo rapido de aplica- 
ciones que algunas personas consideran que es un ejemplo inicial de un metodo agil. O- Stapleton, 1997. Addison- 
Wesley.) 



EJERCICIOS 

17.1 Explique por que la entrega y desarrollo rapidos de sistemas nuevos es a menudo mas importante para las 
empresas que una funcionalidad detallada de estos sistemas. 
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17.2 Explique como los principios subyacentes a los metodos agiles conducen a un desarrollo y utilizacion del 
software acelerados. 

173 iCuando recomendaria contra el uso de un metodo agil para desarrollar un sistema software? 

17A La programacion extrema expresa los requerimientos del usuario como historias, donde cada historia se 
redacta en una tarjeta. Comente las ventajas y desventajas de este enfoque para la descripcion de reque- 
rimientos. 

17.5 Explique por que el desarrollo previamente probado ayuda al programador a desarrollar una mejor com- 
prension de los requerimientos del sistema. ^Cuales son los problemas potenciales del desarrollo previa- 
mente probado? 

17.6 Sugiera cuatro razones por las que el indice de productividad de programadores trabajando en parejas sea 
aproximadamente el mismo que dos programadores trabajando de forma individual. 

17.7 Se le ha pedido que investigue la viabilidad de la consti uccion de prototipos en el proceso de desarrollo 
de software de su organizacion. Redacte un informe para su jefe que explique las clases de proyectos don- 
de se deba utilizar el prototipado, y precise los costesy beneficios esperados de este. 

17.8 Un administrador de software trabaja en el desarrollo de un proyecto de diseho de un sistema de ayuda 
que traduce los requerimientos del software a una especif icacion software formal. Comente las ventajas y 
desventajas de las siguientes estrategias de desarrollo: 

a) Desarrollo de un prototipo desechable, su evaluacion y posterior revision de los requerimientos del 
sistema. Desarrollo del sistema final utilizando C. 

b) Desarrollo del sistema a partir de los requerimientos existentes utilizando Java, posterior modifica- 
cion para que se adapte a cualquier cambio en los requerimientos del usuario. 

c) Desarrollo del sistema utilizando un desarrollo incremental con la participacion del cliente en el equi- 
po de desarrollo. 

17.9 Una organizacion benefica te ha solicitado construir un prototipo de un sistema que de seguimiento al his- 
torial de todas las donaciones que ha recibido. Este sistema tiene que almacenar los nombres y direccio- 
nes de los donantes, sus intereses particulares, la cantidad donada y cuando fue donada. Si la donacion 
esta por encima de cierta cantidad, el donante puede poner condiciones para hacerla (por ejemplo, debe 
gastarse en un proyecto en particular), y el sistema debe mantener el historial de estas y como fueron gas- 
tadas. Comente como construiria el prototipo de este sistema, teniendo presente que la organizacion tie- 
ne una mezcla de trabajadores asalariados y voluntarios. Muchos de los voluntarios son jubilados que tie- 
nen poca o nula experiencia en information. 

17.10 Usted ha desarrollado un prototipo desechable de un sistema para un cliente que esta muy contento con 
el. Sin embargo, sugiere que no existe necesidad de desarrollar otro sistema, sino que debe entregarle el 
prototipo y le ofrece un precio excelente por el. Usted sabe que habra problemas futuros en el manteni- 
miento del sistema. Explique como deberia responder a este cliente. 
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Objetivos 

Los objetivos de este capitulo son introducir la reutilizacion del 
software y explicarcomo la reutilizacion contribuye al proceso de 
desarrollo del software. Cuando haya leido este capitulo: 

• comprendera los beneficios y los problemas de reutilizar 
software cuando se desarrollan sistemas nuevos; 

• habra aprendidovariasformasde jmplementarlareutilizacion 
del software; 

• comprendera el concepto de reutilizacion y como los 
conceptos reutilizabtes se pueden representar como patrones 
o ser embebidos en generadores de programas; 

• habra aprendido como los sistemas pueden desarrollarse 
rapidamente mediante la composicion de grandes aplicaciones 
comerciales; 

• habra sido introducido en las lineas de productos software 
que estan formadas por una arquitectura comun y 
componentes configurables y reutilizables. 

Contenidos 

18.1 El campo de la reutilizacion 

18.2 Patrones de diseno 

18.3 Reutilizacion basada en generadores 

18.4 Marcos de trabajo de aplicaciones 

18.5 Reutilizacion de sistemas de aplicaciones 
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El proceso de diseno en la mayoria de las disciplinas de ingenieria se basa en la reutilizacion 
de sistemas o componentes existentes. Los ingenieros mecanicos o electricos no especifican 
normalmente un diseno en el que cada componente tenga que ser fabricado de una forma es- 
pecial. Basan su diseno en componentes que han sido utilizados y probados en otros sistemas. 
Estos componentes no son solamente pequefios componentes, como tuercas y valvulas sino 
que incluyen subsistemas mayores, como motores, condensadores o turbinas. 

La ingenieria del software basada en reutilizacion es una estrategia de ingenieria del soft- 
ware comparable en la que el proceso de desarrollo es adaptado a la reutilizacion de softwa- 
re existente. Si bien los beneficios de la reutilizacion han sido reconocidos durante muchos 
anos (Mcllroy, 1968), solo en la ultima decada ha existido una transicion gradual desde el des- 
arrollo del software original hasta el desarrollo basado en reutilizacion. La tendencia hacia el 
desarrollo basado en reutilizacion viene dada como respuesta a las demandas de una menor 
produccion de software y de menores costes de mantenimiento, de una entrega mas rapida de 
los sistemas y del incremento en la calidaddel software. Cada vez mas compafiias ven su soft- 
ware como un activo valioso y estan promocionando la reutilizacion para incrementar sus be- 
neficios en las inversiones de software. 

La ingenieria del software basada en reutilizacion es una aproximacion del desarrollo que 
intenta maximizar la reutilizacion del software existente. Las unidades de software que se reu- 
tilizan pueden ser de tamanos totalmente diferentes. Por ejemplo: 

1. Reutilizacion de sistemas de aplicaciones. La totalidad de un sistema de aplicaciones 
puede ser reutilizada incorporandolo sin ningun cambio en otros sistemas, configu- 
rando la aplicacion para diferentes clientes o desarrollando familias de aplicaciones 
que tienen una arquitectura comun pero que son adaptadas a clientes particulares. La 
reutilizacion de sistemas de aplicaciones se trata en la Seccion 18.5. 

2. Reutilizacion de componentes. La reutilizacion de componentes de una aplicacion va- 
ria en tamano desde subsistemas hasta objetos simples. Por ejemplo, un sistema de em- 
parejamiento de patrones desarrollado como parte de un sistema de procesamiento de 
textos puede ser reutilizado en un sistema de gestion de base de datos. Esto se trata en 
el Capitulo 19. 

3. Reutilizacion de objetos y funciones. Pueden reutilizarse componentes software que 
implementan una linica funcion, como por ejemplo una funcion matematica o una cla- 
se de objetos. Esta forma de reutilizacion, basada en librerias estandar, ha sido habi- 
tual en los cuarenta ultimos anos. Estan disponibles muchas librerias de funciones y 
clases para diferentes tipos de aplicaciones y plataformas de desarrollo. Estas pueden 
utilizarse facilmente enlazandolas con codigo de otras aplicaciones. En areas como al- 
goritmos matematicos y graficos, donde se necesita a un experto especifico para desa- 
rro liar objetos y funciones, esta es una aproximacion particularmente efectiva. 

Los sistemas y componentes software son entidades reutilizables especificas, pero su natu- 
raleza especifica significa a veces que el coste de modificarlos para una nueva situacion resul- 
ta elevado. Una forma complementaria de reutilizacion es la reutilizacion de conceptos, en la 
que, en lugar de reutilizar un componente, la entidad reutilizada es mas abstracta y se disena 
para ser configurada y adaptada a una variedad de situaciones. La reutilizacion de conceptos 
puede incluirse en aproximaciones tales como patrones de diseno, productos de sistemas con- 
figurables y generadores de programas. El proceso de reutilizacion, cuando se reutilizan los con- 
ceptos, incluye una actividad de instanciacion en la que los conceptos abstractos se configuran 
para una situacion concreta. Estas dos aproximaciones de reutilizacion de conceptos — patrones 
de diseno y generacion de programas — se tratan mas adelante en este capitulo. 
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La ventaja obvia de la reutilizacion de software es que los costes totales de desarrollo de- 
berian reducirse. Se necesita especificar, disefiar, implementar y validar menos componentes 
software. Sin embargo, la reduccionde costes es solo una ventaja de la reutilizacion. En laF i- 
gura 18.1. se muestran otras ventajas de la reutilizacion de activos software. 

Sin embargo, hay tambien costes y problemas asociados con la reutilizacion (Figura 18.2). 
En particular, hay un coste significativo asociado con el estudio de si un componente es apro- 
piado para su reutilizacion en una situacion concreta y con la prueba de ese componente para 
asegurar su confiabilidad. Estos costes adicionales pueden inhibir la introduccion de la reuti- 
lizacion y puede implicar que las reducciones de los costes totales de desarrollo mediante reu- 
tilizacion sean menores que las de los costes anticipados. 

La reutilizacion sistematicano se lleva acabo sin mas, sino que debe serplanificada e in- 
troducida ampliamente en una organizacion a traves de un programa de reutilizacion. Esto ha 
sido reconocido durante muchos anos en Japon (Matsumoto, 1984), endonde la reutilizacion 
es una parte integral de laaproximacion de «factoria» japonesa al desarrollo del software (Cu- 
samano, 1989). Companiascomo Hewlett-Packard han experimentado con exito la reutiliza- 
cion de programas (Griss y Wosser, 1995). y su experiencia ha sido incorporada en un libro 
de proposito general por Jacobsen y otros (Jacobsen et ai, 1997). 
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El software reutiltzado, que ha sido usado y probado en 
sistemas en fundonamiento, deberfa ser mas confiable que ei 
software nuevo debido a que sus f altos en la implementation y 
el dtseno ya han sido encorrtrados y reparados. 

El coste del software existente ya es conocido, mientras que 
el coste de desarrollo es siempre cuestionable. Este es un 
factor importante para la gestion de prayectos debido a que 
reduce el margen de error en la estimation de costes del 
proyecto. Esto es particularmente cierto cuando se reutiKzan 
componentes software relativamerrte grandes tales como 
subsystem as. 



Uso efectivo 
de especiatistas 



Cumplimiento 
de estdndares 



En lugar de hacer el mismo trabajo una y otra vez, estos 
especial istas de aplkaciones pueden desarrollar software 
reurJIizable que encapsule su conocimiento. 

Algurtos estilndares, tales como los estandares de interfaz de 
usuario, pueden implementarse como un con junto de 
componentes reutilizables estandar. Por ejemplo, si los menus 
en un interfaz de usuario se implementan usando componentes 
reutilizables, todas las a plica clones presentan el mismo formato 
de menu a los usuarios. El uso de interfaces de usuario 
esrindares mejora la confiabilidad debido a que es menos 
probable que los usuarios cometan errores cuando se 
encuentran con una interfaz familiar. 



Figura 18.1 
Beneficios de la 
reutilizacion de 
software. 



Desarrollo acelerado 



Sacar al mercado un sistema tan pronto como sea posible es a 
menudo mis importante que los costes totales de desarrollo. La 
reutilizacion del software puede acelerar la producti6n del 
sistema debido a que se reducen los tjempos de desarrollo y 
validacidn. 
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Problema 



Explicaci6n 



tnaemento en k>s costes 
de itiinteninwnto 



Fella de soporte 
de las henamientas 



Si d codtgo fuente de un sistema de software reutibzado oun 
componente no esta disponMe, entonces las costes de 
mantenirniento pueden ncrementsne dcbido a que los 
elementos reunlizados del sistema son cada vez mas 
mcompatibles con los cambios del sistema. 

Los eon ju n to s de henamientas CASE no soportan ei desanolo 
con reutiGzacion. Puede ser dMril o imposibte integrar eslas 
hemmientas con un sistema de Rmria de componentes. El 
proceso d«< software esumtdo por estas henamientas puede no 
tener en cuenta la reutMrzarion. 



Figura 18.2 

Problemas con la 
reutilizacion. 



Sindrome 

tiemventar la rueda> 



Creaoon y rnantenimiento 
de una Rbreria 
de componentes 



Bosqueda, comprenslon 
y adaptacidn 
de componentes 
reutaizables 



AJgunos ingeniefos software prefieren rencribir componentes 
debido a que aeen que pueden mejorarios. Esto es en parte 
derto ya que la escritur a original de soft wa re es vista como un 
reto mayor que la utifizadon de s o ft wa re de otras personas. 

Puede ser csro cowtnrir una Gbrerfa de componentes 
reutiEzabie v asegufar que los dssaiioftadofes de software 
puedan usarla. Las tecnicas actuates pan dasificar, catalogar y 
recti perar componentes software son todavia inmaduras. 

Los componente s software town que buscarse en una Nbrerfa, 
entendene y, algunas veces, adaptane al trabajo en un entomo 
nuevo. Los i n ge ni cr os deben confer razonaWemente en que 
van a encontrar un componente en la Rbreria antes de que 
puedan indue* la bosqueda de un c om ponen t e como parte de 
su proceso normal de desanolo. 



18.1 El campo de la reutilizacion 

Durante los veinte ultimos anos, se han desarrollado muchas tecnicas para soportar la reutili- 
zacion del software. Estas explotan el hecho de que los sistemas del mismo dominio de apli- 
cacion son similares y tienenpotencial para la reutilizacion. Esta reutilizacion es posible a di - 
ferentes niveles (desde funciones simples a aplicaciones completas), y los estandares para 
componentes reutilizables facilitan la reutilizacion. La Figura 18.3 muestra varias formas de 
soportar la reutilizacion del software, cada una de las cuales se describe brevemente en la Fi- 
gura 18.4. 

Dada esta lista de tecnicas para reutilizacion, la cuestion clave es ^cual es la tecnica mas 
adecuada a utilizar? Obviamente, esto depende de los requerimientos del sistema a desarro- 
llar, la tecnologiay activos reutilizables disponibles, y la experiencia del grupo de desarrollo. 
Los factores clave que deberian considerarse a la hora de planificar la reutilizacion son: 

1. La agenda de desarrollo del software. Si el software tiene que desarrollarse rapida- 
mente, deberia intentarse reutilizar sistemas comerciales en vez de componentes indi- 
viduals. Estos son activos reutilizables de grano grueso. Si bien el cumplimiento de 
los requerimientos puede no serperfecto, esta aproximacion minimiza la cantidad de 
desarrollo requerido. 

2. Vida esperada del software. S i se esta desarrollando un sistema de larga vida, habria 
que centrarse en la mantenibilidad del sistema. En esas circunstancias, no solamente 



18.1 • El campo de la reutilizacion 



383 




Aproximacion 
Patrones de diseno 



Desarrollo basado 
en componentes 



Descrlpclon 

Las abstracciones genericas similares entre aplicaciones se 
representan como patrones de diseno que muestran los objetos 
abstractos y concretos y sus interacciones. 

Los sistemas se desarrollan integrando componentes 
(colecciones de objetos) que cumplen los estandares de 
modelado de componentes. Esto se trata en el Capitulo 19. 



Marcos de aplicaciones 



Envoltura de sistemas 
heredados 



Las colecciones de dases concretas y abstractas pueden 
adaptarse y extenderse para crear sistemas de aplicaciones. 

Sistemas heredados (vease el Capitulo 2) que pueden ser 
«envueltos» definiendo un conjunto de interfaces y 
proporcionando acceso a estos sistemas heredados a traves de 
estas interfaces. 



Sistemas orientados 
a servicios 

lineas de productos 
de aplicaciones 



Los sistemas se desarrollan enlazando servicios compartidos, 
que pueden ser proporcionados de forma externa. 

Un tipo de aplicacion se generaliza alrededor de una 
arquitectura comun para que pueda ser adaptada para 
diferentes dientes. 



Integration COTS 



Los sistemas se desarrollan integrando sistemas de aplicaciones 
existentes. 



Aplicaciones verticales 
configurables 

Librenas de programas 



Un sistema generico se diseha para que pueda configurarse 
para las necesidades de dientes de sistemas particulares. 

Estan disponibles para reutilizacion las librenas de funciones y 
de dases que implementan abstracciones comunmente usadas. 



Figura 18.4 

Aproximaciones que 
soportan la 
reutilizacion del 
software. 



Generadores 
de programas 



Desarrollo del software 
orientado a aspectos 



Un sistema generador incluye conocimiento de un tipo de 
aplicacion particular y puede generar sistemas o fragmentos de 
un sistema en ese dominio. 

Componentes compartidos entrelazados en una aplicacion en 
diferentes lugares cuando se compila el programa. 
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deberia pensarse en las posibilidades inmediatas de la reutitizacion, sino tambien en 
las implicaciones a largo plazo. Se tendra que adaptar el sistema a nuevos requeri- 
mientos, lo cual probablemente signifique hacer cambios a los componentes y como 
estos son utilizados. Si no se tiene acceso al codigo fuente, probablemente deberia evi- 
tarse utilizar componentes y sistemas de proveedores externos; no se puede estar se- 
guro de que estos proveedores seran capaces de continuar soportando el software reu- 
ti 1 izado. 

3 . Los conocimientos, habilidades y experienced del grupo de desarrollo. Todas las tecno- 
logias de reutilizacion son bastante complejas y se necesita bastante tiempo para com- 
prenderlas y usarlas de forma efectiva. Sin embargo, si el grupo de desarrollo posee ha- 
bilidades en un area particular, probablemente habria que centrarse en ella. 

4. La criticidad del software y sus requerimientos no funcionales. Para un sistema criti- 
co que tiene que ser certificado por un regulador externo, se tiene que crear un caso de 
confiabilidad para el sistema (tratado en el Capitulo 24). Esto es dificil si no se tiene 
acceso al codigo fuente del software. Si el software tiene requerimientos de rendi- 
miento estrictos, puede ser imposible utilizar estrategias tales como reutilizacion a tra- 
ves de generadores de programas. Estos sistemas tienden a generar codigo relativa- 
mente ineficiente. 

5. El dominio de las aplicaciones. En algunos dominios de aplicaciones como los siste- 
mas de informacion medica y de fabricacion, hay varios productos genericos que pue- 
den reutilizarse para configurarlos a una situacion particular. Si se esta trabajando en 
tales dominios, siempre deberian considerarse estos como una opcion. 

6. La platafornta sobre la que el sistema se va a ejecutar. Algunos modelos de compo- 
nentes, como COM/Active X, son plataformas especificas de Microsoft. Si se esta 
desarrollando sobre una plataforma como estas, esta aproximacion puede ser la mas 
adecuada. De igual forma, los sistemas de aplicaciones genericos pueden ser plata- 
formas especificas y solamente es posible reutilizartos si el sistema se disefia para la 
misma plataforma. 

La cantidad de sistemas de reutilizacion disponibles es tal que, en la mayoria de las situa- 
ciones, existe la posibilidad de alguna reutilizacion del software. Si se consigue o no la reu- 
tilizacion es a menudo una cuestion de gestion mas que una cuestion tecnica. Los gestores 
pueden ser reacios a comprometer sus requerimientos para permitir el uso de componentes 
reutilizables, o pueden decidir que el desarrollo de componentes originales podria ayudar a 
crear una base de activos software. Es posible que no comprendan los riesgos asociados con 
la reutilizacion tan bien como entienden los riesgos del desarrollo original. Sin embargo, si 
bien los riesgos de un nuevo desarrollo software pueden ser mas elevados, algunos gestores 
pueden preferir los riesgos conocidos a los desconocidos. 

18.2 Patrones de diseho 

Cuando el disefiador intenta reutilizar componentes ejecutables, esta limitado de forma in- 
evitable por las decisiones de diseno detallado que han sido tomadas por los implementado- 
res de esos componentes. Estas varian desde algoritmos particulares que han sido utilizados 
para implementar los componentes hasta los objetos y tipos en las interfaces de los compo- 
nentes. Cuando estas decisiones de diseno estan en pugna con sus requerimientos particula- 
res, reutilizar el componente es imposible o introduce ineficiencias en su sistema. 
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Una forma de solventar esto es reutilizar disefios abstractos que no incluyen detalles de 
la implementacion. El diseftador puede implementarlos para ajustarse a sus requerimientos 
particulares de la aplicacion. Las primeras instancias de esta aproximacion para reutilizacion 
aparecieron en la documentacion y publicacion de algoritmos fundamentales (Knuth. 1971) 
y, mas tarde, en la documentacion de tipos abstractos de datos tales como pilas, arboles y lis- 
tas (Booch, 1987). Mas recientemente, esta aproximacion para la reutilizacion ha sido in- 
cluida en los patrones de diseno. 

Los patrones de diseno se derivaron de las ideas introducidas por Christopher Alexander 
(Alexander et al, 1977), quien sugirio que existian ciertos patrones del diseno de edificios que 
eran comunes e inherentemente interesantes y efectivos. El patron es una descripcion del pro- 
blema y la esencia de su solucion, de forma que la solucion se pueda reutilizar en diferentes 
situaciones. El patron no es una especificacion detallada. Antes bien, puede pensarse en el 
como una descripcion del conocimiento y experiencia acumulados. Es una solucion adecua- 
da a un problema comun. Una frase del sitio web hillside.net , que se dedica a mantener in- 
formacion sobre patrones, encapsula su papel en la reulilizacion: 

Los patrones y los lenguajes de patrones son formas de describir las mejores prdcticas, 
buenos dlsehos,y encapsulan la experiencia de tai forma que es poslble para otros el 
reutilizar dlcha experiencia. 

La mayoria de los disefiadores piensan en los patrones de diseno como una forma de so- 
portar el diseno orientado a objetos. Los patrones u menudo tienen en cuenta caracteristicas 
de los objetos tales como la herencia y el polimorfismo para proporcionar generalidad. Sin 
embargo, el principio general de encapsulacion de experiencia en un patron es que es igual- 
mente aplicable a todas las aproximaciones de diseno software. 

Gamma y otros (Gamma et ah, 1995) definen los cuatro elementos esenciales de los pa- 
trones de diseno: 

1. Un nombre que es una referencia significativa del patron. 

2. Una descripcion del area del problema que explica cuando puede aplicarse el patron. 

3. Una descripcion de las partes de la solucion del diseno, sus relaciones y sus respon- 
sabilidades. Esta no es una descripcion concreta de diseno. Es una plantilla para una 
solucion de diseno que puede instanciarse de diferentes formas. A menudo esta se ex- 
presa graficamente y muestra las relaciones entre los objetos y las clases de los obje- 
tos en la solucion. 

4. Una declaracion de las consecuencias — los resultados y compromisos — de aplicar el 
patron. Esto puede ayudar a los disefiadores a comprender si un patron puede ser apli- 
cado de forma efectiva en una situacion particular. 

Estos elementos esenciales de la descripcion de un patron pueden descomponerse, tal y 
como se muestra en el ejemplo de la Figura 18.5. Por ejemplo. Gamma y sus coautores divi- 
den la descripcion del problema en motivacion (una descripcion de por que el patron es util) 
y aplicabilidad (una descripcion de las situaciones en las que el patron puede utilizarse). Bajo 
la descripcion de la solucion, ellos describen la estructura del patron, participantes, colabora- 
ciones e implementacion. 

Para ilustrar la descripcion de patrones, utilizamos el patron Observer, tornado del libro de 
Gamma y otros. Este patron puede utilizarse en una gran variedad de situaciones en las que 
se requieren diferentes presentaciones del estado de un objeto. Separa el objeto que debe ser 
visualizado de las diferentes formas de presentacion. Esto se ilustra en la Figura 18.6. que 
muestra dos presentaciones graficas del mismo conjunto de datos. En la descripcion, se utili- 
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Howbra del potrea: Observer 

Pejcrlpclea: Separa la vista del estado de un objeto del objeto mismo y permite 
proporcionar vistas alternativas. Cuando el estado del objeto cambia, todas las vistas son 
ratificadas y actualizadas de forma automatica para reflejar el cambia 

Paulpllee asl problems: En muchas situaciones es necesario proporcionar multiples vistas 
de alguna informacion del estado, tal corno una vista grafica y una vista tabular. No todos 
ellos pueden ser conocidos cuando se especifica la informacion. Todas las presentaciones 
alternativas pueden soportar interaccion y, cuando el estado se cambia, deben actualizarse 
todas las vistas. 

Este patron puede utilizarse en todas las situaciones en las que se requiera mas de un 
formato de vista para la informacion del estado y en las que no es necesario que d objeto 
que mantenga la informacion del estado conozca los formatos espeofficos utilizados para las 
vistas. 

Pelutpcfew de le soluclon: La estructura del patron se muestra en la Figura 18.7. Esta 
define dos objetos abstractos, Subject y Observer, y dos objetos concretos, ConcreteSubject y 
ConcreteObserver, que heredan los atributos de los objetos abstractos relacionados. El estado 
a visualizar es mantenido en ConcreteSubject, que tambien hereda las operaciones de Subject 
permitiendole anadir y eliminar Observeis y enviar una notificacion cuando el estado ha 
cambiado. 

El objeto ConcreteObserver mantiene una copia del estado de ConcreteSubject e implemento 
la interfaz Update 0 de Observer, que permite guardar estas copias en el mismo momento. 
FJ objeto ConcreteObservef visualiza automaticamente su estado -esto no es generalmente 
una operacion de interfaz. 

Cee»ac — daa: El objeto Subject solamente conoce el Observer abstracto y no conoce tos 
detalles de la dase concreta. For ello hay un minimo acoplamiento entre estos objetos. 
Debido a esta falta de conocimiento, las optimizaciones que mejoran el rendimiento de la 
visualizadon no son practicas. Los cambios en el objeto Subject pueden provocar la 

Figura 18.5 generacion de un conjunto de actualizaciones vinculadas con los objetos Observers, algunas 

Una descripcion del de las cuales pueden no ser necesarias. 

patron Observer. 



zan las descripciones de los cuatro elementos fundamentales y los complemento con una bre- 
ve declaracion de lo que el patron puede hacer. 

Las representaciones graficas se utilizan normalmente para ilustrar las clases de objetos 
que se usan en patrones y sus relaciones. Esta descripcion del patron complementa y afiade 
detalles a la descripcion de la solucion. La Figura 18.7 es la representacion en UML del pa- 
tron Observer. 



Figura 18.6 




Multiples vistas. 
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Subject 

Attach (Observer) 
Detach (Observer) 
Notify 0 

A 



para todos los objetos en 
o -> Update 0 



Observer 



Update 0 



7^ 



ConcreteSubject 



GetState 0 
subjectState 



return subjectState 



ConcreteObserver 



Update 0 



obsetverState 



observerState = 
subject -> GetState 



Figura 18.7 El patron Observer. 



Actualmente estan disponibles un elevado numero de patrones publicados (veanse las pa- 
ginas web del libro para enlaces) que abarcan varios dominios de aplicaciones y lenguajes. 
La nocion de un patron como un concepto reutilizable ha sido desarrollada en varias areas ade- 
mas del disefio software, que incluye gestion de configuraciones, disefio de interfaces de 
usuarioy escenarios de interacciones (Berczuky Appleton, 2002; Borchers, 2001; Martin et 
al, 2001; Martin etal, 2002). 

El uso de patrones es una forma efectiva de reutilizacion. Sin embargo, se puede afirmar 
que solo ingenieros software experimentados que tengan un conocimiento profundo de pa- 
trones pueden utilizarlos de forma efectiva. Estos desarrolladores pueden reconocer situacio- 
nes genericas en las que se puede aplicar un patron. Los programadores sin experiencia, aun 
cuando hayan leido libros sobre patrones, siempre encontraran dificil decidir si pueden reuti- 
lizar un patron o si necesitan desarrollar una solucion de proposito especifico. 



18.3 Reutilizacion basada en generadores 

El concepto de reutilizacion mediante patrones tiene que ver con la descripcion del concepto 
de una forma abstracta y dejando al desarrollador la labor de crear una implementacion. Una 
aproximacion alternativa a esta es la reutilizacion basada en generadores (Biggerstaff, 1998). 
En esta aproximacion, el conocimiento reutilizable se captura enun sistemageneradorde pro- 
gramas que puede ser programado por expertos en el dominio utilizando un lenguaje orienta- 
do a dominios o una herramienta CASE interactiva que soporte la generacion de sistemas. La 
descripcion de la aplicacion especifica, de forma abstracta, que componentes reutilizables tie- 
nen que usarse y como tienen que ser combinados y parametrizados. Utilizando esta infor- 
macion se puede generar un sistema software operativo (Figura 18.8). 



Figura 18.8 
Reutilizacion basada 
en generadores. 



Descripcibn de 
la aplicaci6n 



K 



Generador 
^eL^ro^rarna^ 



Conocimiento del 
dominio de aplicacibn 



Programa generado 



Base de datos I 
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La reutilizacion basada en generadores se aprovecha del hecho de que las aplicaciones del 
mismo dominio, tales como sistemas de negocio, tienen arquitecturas comunes y realizan fun- 
ciones comparables. Por ejemplo, como se indica en el Capitulo 13, los sistemas de procesa- 
miento de datos normalmente siguen un modelo de entrada-proceso-salida y suelen incluir 
operaciones tales como verificacion de datos y generacion de informes. Por lo tanto, pueden 
crearse componentes genericos y ser incorporados en un generador de aplicaciones para se- 
leccionar elementos de una base de datos, comprobar que estos estan dentro del rango per- 
mitido y para elaborar informes. Para reutilizar estos componentes, el programador simple- 
mente tiene que seleccionar los datos a utilizar, las comprobaciones que deben aplicarse y el 
formato de los informes. 

La reutilizacion basada en generadores ha tenido exito sobre todo para sistemas de aplica- 
ciones de negocios, y existen muchos productos generadores de aplicaciones de negocios dis- 
ponibles. Estos pueden generar aplicaciones completas o pueden automatizar parcialmente la 
creacion de aplicaciones y dejar que el programador las complete condetalles especificos. La 
aproximacion a la reutilizacion basada en generadores tambien se utiliza en otras areas, in- 
cluyendo: 

1 . Generadores de analizadores para el procesamiento del lenguaje. La entrada del ge- 
nerador es una gramatica que describe el lenguaje que va a ser analizado, y la salida 

es el analizadordel lenguaje. Esta aproximacion se incluye en sistemas tales como lex 
y yace para C y JavaCC, un compilador de Java. 

2 . Generadores de cddigo en herramientas CASE. La entrada de estos generadores es un 
diseno softwarey la salida es un programaque implementael sistemadisefiado. Pue- 
den basarse en modelos U M L y, dependiendo de la informacion en los modelos U M L , 
generar un programa completo o componente, o bien un esqueleto de codigo. El 
desarrolladordel software a continuacion aflade detalles para completar el codigo. 

Estas aproximaciones a la reutilizacion basada en generadores se aprovechan de la estructu- 
ra comun de las aplicaciones en estas areas. La tecnica tambien ha sido usada en dominios de 
aplicaciones mas especificos, tales como sistemas de control y de ordenes (O'Connor et ah, 
1994) e instrumentacion cientifica (Butler, 1994), donde se han desarrollado librerias de com- 
ponentes. Los expertos del dominio utilizan un lenguaje especifico del dominio para componer 
estos componentes y crear aplicaciones. Sin embargo, existe un alto coste inicial en la defini- 
cion e implementacion de los conceptos del dominio y en el lenguaje de composicion. Esto sig- 
nifica que muchas companias son reacias a asumir los riesgos de adoptar esta aproximacion. 

La reutilizacion basada en generadores es rentable para aplicaciones tales como procesa- 
miento de datos de negocios. Es mucho mas sencillo para los usuarios finales desarrollar pro- 
gramas utilizando generadores frente a otras aproximaciones basadas en componentes para la 
reutilizacion. Sin embargo, inevitablemente hay deficiencias en los programas generados. 
Esto significa que puede ser imposible utilizar esta aproximacion en sistemas con requeri- 
mientos de elevado rendimiento. 

La programacion generativa es un componente clave de tecnicas emergentes de desarrollo 
de software que combina la generacion de programas con el desarrollo basado en componen- 
tes. El libro de Czarnecki y Eisenecher (Czamecki y Eisenecher, 2000) describe estas nuevas 
aproximaciones. 

La mas desarrollada de estas aproximaciones es el desarrollo de software orientado a as- 
pectos (AOSD)(Elrad VI al., 2001). El desarrollo de software orientado a aspectos aborda uno 
de los mayores problemas en el diseno del software: el problema de la separacion de intere- 
ses. La separacion de intereses es un principio de diseno basico; deberia diseflarse el software 
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para que cada unidad o componente haga una y solo una cosa. Por ejemplo, en el sistema 
LIB SYS . deberia haberun componente dedicado a la busqueda de documentos, un compo- 
nente dedicado a la impresion de documentos, un componente dedicado a la gestion de des- 
cargas, y asi sucesivamente. 

Sin embargo, en muchas situaciones los intereses no se asocian a funciones de aplicacio- 
nes claramente definidas, sino que estan compartidos; es decir, afectan a todos los compo- 
nentes del sistema. Por ejemplo, supongamos que se quiere seguir la pista del uso de cada uno 
de los modulos del sistema por cada usuario del sistema. Por lo tanto, se tiene un interes en 
monitorizar que tiene que asociarse a todos los componentes. Esto no puede ser simplemen- 
te implementado como un objeto referenciado por dichos componentes. La monitorizacion es- 
pecifica que tiene que llevarse a cabo necesita informacion de contexto de la funcion del sis- 
tema que esta siendo monitorizada. 

En la programacion orientada a aspectos, los intereses compartidos se implementan como 
aspectos y, dentro del programa, se define donde se deberia asociar un aspecto. Estos se de- 
nominanpuntos de enlace. Los aspectos se desarrollan de forma separada; acontinuacion, en 
un paso de precompilacion denominado entrelazado de aspectos, son enlazados mediante los 
puntos de enlace (Figura 18.9). El entrelazado de aspectos es una forma de generacion de pro- 
gramas; la salida del proceso de entrelazado es un programa en el que se ha integrado el co- 
digo del aspecto. Un desarrollo de Java denominado AspectJ (Kiczales etal, 2001) es el len- 
guaje mejor conocido para el desarrollo orientado a aspectos. 

Actualmente el desarrollo AO S D es un tema de investigacion importante, pero todavia no 
se ha generalizado su uso para el desarrollo industrial de software. Existen problemas con esta 
aproximacion: el codigo generado nunca es tan eficiente como el codigo escrito manualmen- 
te, y necesitamos un mejor conocimiento de las relaciones entre los aspectos y las propieda- 
des no funcionales del sistema. Sin embargo, enpocos anos, se esperaque AO SD se convierta 
en una aproximacion importante para la reutilizacion del software, en donde los aspectos pue- 
dan ser reutilizados entre las aplicaciones. 



18.4 Marcos de trabajo de aplicaciones 

Las primeras personas que propusieron el desarrollo orientado a objetos sugirieron que los ob- 
jetos eran la abstraccion mas adecuada para la reutilizacion. Sin embargo, la experiencia ha 
demostrado que los objetos son a menudo de grano muy fino y demasiado especializados para 
una aplicacion particular. Porotro lado, estaclaro que la reutilizacion orientada a objetos esta 
mejor soportada en un proceso de desarrollo orientado a objetos a traves de abstracciones de 
grano mayor denominadas marcos de trabajo. 
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Un marco de trabajo (o marco de trabajo de aplicaciones) es un diseno de un subsisten" 
formado por una coleccion de clases concretas y abstractas y la interfaz entre ellas (Wiri 
Brock y Johnson, 1990). Los detalles particulars del subsistemade aplicacion son implt 
mentados afiadiendo componentes y proporcionando implementaciones concretas de II 
clases abstractas en el marco de trabajo. Los marcos de trabajo raramente son aplicaciont 
por si mismos. Las aplicaciones se construyen normalmente integrando varios marcos c 
trabajo. 

Fayad y Schmidt (Fayad y Schmidt, 1997) describen tres clases de marcos de trabajo: 

1 . Marcos de trabajo de infraestructura de sistemas. Estos marcos de trabajo soportan 4 
desarrollo de infraestructuras de sistemas tales como comunicaciones, interfaces d 
usuario y compiladores (Schmidt, 1997). 

2. Marcos de trabajo para la integration de middleware. Consisten en un conjunto d 
estandares y clases de objetos asociados que soportan la comunicacion de compc 
nentes y el intercambio de informacion. Ejemplos de este tipo de marcos son COF 
B A, COM+ de Microsoft y Enterprise Java Beans. Estos marcos proporcionan se 
porte para modelos de componentes estandarizados, tal y como se expone en ( 
Capitulo 19. 

3. Marcos de trabajo de aplicaciones empresariales. Se refieren a dominios de aplici 
ciones especificos tales como telecomunicaciones o sistemas financieros (Baumer< 
al, 1997). Estos marcos de trabajo encapsulan el conocimiento del dominio de la api 
cacion y soportan el desarrollo de aplicaciones para los usuarios finales. 

Tal y como el nombre sugiere, un marco de trabajo es una estructura generica que pued 
ser extendida para crear un subsistema o aplicacion mas especifico. Este es implementad 
como una coleccion de clases de objetos concretas y abstractas. Para extender el marco de tn 
bajo, se tienen que anadir clases concretas que hereden operaciones de las clases abstract: 
en el marco, Ademas se deben definir callbacks. Los callbacks son metodos que se llama 
como respuesta a eventos reconocidos por el marco de trabajo. 

Uno de los marcos de trabajo mas conocido y ampliamente usado para el diseno de GU 
es el marco Modelo-Vista-Controlador (MVC) (Figura 18.10). El marco de trabajo MVC fi 
propuesto originalmente en la decada de los 80 como una aproximacion al diseno de GU 
que permitio multiples presentaciones de un objeto y estilos independientes de interaccion ce 
cada una de estas presentaciones. El marco MVC soporta la presentacion de los datos de d 
ferentes formas (vease la Figura 18.6) e interacciones independientes con cada una de est; 
presentaciones. Cuando los datos se modifican a traves de una de las presentaciones, el resi 
de las presentaciones son actualizadas. 
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Los marcos de trabajo son a menudo instanc i aciones de varios patrones, tal y como se vio 
en la Seccion 18.2. Por ejemplo, el marco M V C incluye el patron Observer descrito en la F i - 
gura 1 8.5, el patron Strategy relacionado con la actualizacion del modelo, el patron Compo- 
site y otros patrones descritos por Gamma y colaboradores (Gamma etal., 1995). 

Las aplicaciones construidas utilizando marcos de trabajo pueden ser las bases para una pos- 
terior reutilizacion a traves del concepto de lineas de productos software o familias de aplica- 
ciones, tal y como se indica en la Seccion 18.5.2. Debido a que estas aplicaciones se constru- 
yen utilizando un marco, se simplifica la modificacion de miembros de la familia para crear 
nuevos miembros. 

El problema fundamental con los marcos de trabajo es su complejidad inherente y el tiem- 
po que lleva aprender a utilizarlos. Pueden requerirse varios meses para comprender comple- 
tamente el marco de trabajo, por lo que es muy probable que, en organizaciones grandes, al- 
gunos ingenieros software se conviertan en especialistas en marcos de trabajo. No hay duda 
de que esta es una aproximacion efectiva para la reutilizacion, pero es muy elevado el coste 
que supone introducirla en los procesos de desarrollo del software. 

18.5 Reutilizacion de sistemas de aplicaciones 

La reutilizacion de sistemas de aplicaciones implica reutilizar sistemas de aplicaciones com- 
pletes configurando un sistema para un entorno especifico o integrando dos o mas sistemas 
para crear una nuevaaplicacion. Tal y como se sugirio en la Seccion 18.1, la reutilizacion de 
sistemas de aplicaciones es a menudo la tecnica de reutilizacion mas efectiva. Implica la reu- 
tilizacion de activos de grano grueso que pueden serrapidamente configurados para crear un 
nuevo sistema. 

En esta seccion, se analizan dos tipos de reutilizacion de aplicaciones: la creacion de nue- 
vos sistemas integrando dos o mas aplicaciones comerciales y el desarrollo de lineas de pro- 
ductos. Una linea de productos es un conjunto de sistemas basados en una arquitectura base 
comun y componentes compartidos. El sistema base se disena de forma especifica para ser 
configurado y adaptado a fin de adecuarse a las necesidades especificas de los diferentes clien- 
tes del sistema. 

18.5.1 Reutilizacion de productos COTS 

La denominacion producto COTS se aplica a un sistema software que puede utilizarse sin 
cambios por su comprador. Virtualmente todo el software de sobremesa y un gran numero de 
productos servidores son software COTS. Debido a que este software se disena para uso ge- 
neral, normalmente incluye muchas caracteristicas y funciones para que sea potencialmente 
reutilizable en diferentes aplicaciones y entornos. Si bien puede haber problemas con esta 
aproximacion para la construccion de sistemas (Tracz, 2001), existe un numero creciente de 
experiencias con exito que demuestran su viabilidad (Baker, 2002; Balk y Kedia, 2000; Pfarr 
yReis,2002). 

Algunos tipos de productos COTS han sido reutilizados durante muchos anos. Los siste- 
mas de bases de datos constituyen quiza el mejor ejemplo de esto. Muy pocos desarrollado- 
res podrian tomar en consideracion la implementacion de su propio sistema de gestion de base 
de datos. Sin embargo, hasta mediados de los 90. solamente existian unos cuantos sistemas 
grandes, como los sistemas de gestion de bases de datos y monitores de teleprocesamiento, 



392 



CAPITULO 18 • Reutilizacion det software 



que fueran reutilizados de forma rutinaria. La mayoria de los sistemas grandes se disenabj 
como sistemas unicos, y a menudo habia muchos problemas en conseguir que estos sistem; 
trabajasen de forma conjunta. 

En la actualidad, es normal para los sistemas grandes el tener definidas Interfaces < 
Programacion de Aplicaciones (APIs) que permiten programar el acceso a las funciones ( 
dichos sistemas. Esto significa que la creacion de grandes sistemas tales como sistemas de o 
mercio electronico mediante la integracion de varios sistemas COTS deberia considerar; 
siempre como una opcion seria de diseno. Debido a la funcionalidad que estos product) 
COTS ofrecen, es posible reducir costes y tiempos de entrega en varios ordenes de magniti 
comparados con el desarrollo de nuevo software. Ademas, los riesgos pueden reducirse ya qi 
el producto se encuentra disponible y los gestores pueden ver si dicho producto satisface si 
requerimientos. 

Para desarrollar sistemas utilizando productos COTS, se tienen que tomar varias elecci 
nes de diseno: 

1. iQue productos COTS ofrecen la funcionalidad mas adecuada? S i todavia no se ti 
ne experiencia con un producto COTS, puede serdificil decidirque producto es el m 
adecuado. 

2. tComo se inter cambiar an los clatos? En general, los productos individuales utiliz; 
estructuras de datos y formatos unicos, y se tienen que escribir adaptadores para co 
vertirunarepresentacion en otra. 

3. iQue caracteristicas de un producto se utilizardn realmente? La mayoria de los pr 
duelos COTS poseen mas funcionalidades de las que se necesitan, y las funcionalid 
des a menudo se duplican entre diferentes productos. Se tiene que decidir qi 
caracteristicas de que productos son las mas adecuadas para los propios requerirme 
tos. Si es posible, deberia tambien denegarse el acceso a funcionalidades no utilizad 
debido a que pueden interferir en el funcionamiento normal del sistema. El fallo del pi 
mervuelo del cohete Ariane 5, comentado en el Capitulo 19 (Nuseibeh, 1997), se d 
bio a un fallo en una funcionalidad no utilizada de un subsistema reutilizado. 

Como ejemplo de una integracion COTS, supongamos que una gran organizacion quie 
desarrollar un sistema de adquisiciones que permite al personal emitir ordenes desde su equ 
po de sobremesa. Introduciendo este sistema dentro de la organizacion, la compania estin 
que puede ahorrar 5 millones de dolares al ano. Al centralizar las compras, el nuevo sisten 
de adquisiciones puede asegurar que los pedidos siempre se realizan a los proveedores qi 
ofertan los mejores precios y se deberian reducir los costes del papeleo asociado con los p 
didos. Al igual que ocurre con los sistemas manuales, esto implica elegir los productos di 
ponibles de un proveedor, crear un pedido, obtener la aprobacion del pedido, enviar el ped 
do a un proveedor, recibir los productos y confirmar que los pagos se efectuen. 

La empresa ya posee un sistema de pedidos que es utilizado por el departamento de ai 
quisiciones. Este ya esta integrado con sus sistemas de facturacion y reparto. Para crear el ru< 
vo sistema de pedidos, se integra el sistema antiguo con una plataforma de comercio electn 
nico basada en web y un sistema de correo electronico que gestiona las comunicaciones ce 
los usuarios. Laestructura del sistema de adquisiciones resultante construido utilizando COI 
se muestra en la Figura 18,1 1. 

Este sistema de adquisiciones es un sistema cliente-servidor, y en el cliente se utiliza i 
navegador web y un software de correo electronico estandares. Estos ya estan integrados p 
los proveedores del software. En la parte del servidor, la plataforma de comercio electronic 
tiene que integrarse con el sistema de adquisiciones existente mediante un adaptador. El si 
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tema de comercio electronico tiene su propio formato para los pedidos, conformidades con 
las entregas, y asi sucesivamente, los cuales tienen que convertirse al formato utilizado por el 
sistema de pedidos. En el sistema de comercio electronico esta integrado el sistema de correo 
electronico para enviar las notificaciones a los usuarios, pero el sistema de pedidos nunca fue 
disefiado para esto. Por lo tanto, tiene que desarrollarse otro adaptador para convertir las no- 
tificaciones en mensajes de correo electronico. 

En principio, el uso de un sistema COTS a gran escala es el mismo que el uso de cualquier 
otro componente mas especifico. Se tienen que comprender las interfaces del sistema y hay 
que utilizarlas exclusivamente para comunicarse con el componente: se tiene que buscar un 
equilibrio entre los requerimientos especificos y el desarrollo rapido y la reutilizacion; y se 
tiene que diseiiaruna arquitectura del sistema que permita que los sistemas COTS operen con- 
juntamente. 

Sin embargo, el hecho de que estos productos son normalmente sistemas grandes y a me- 
nudo se venden como sistemas independientes y unicos, introduce problemas adicionales. 
Boehm y Abts (Boehm y Abts. 1999) plantean cuatro problemas con la integracion de siste- 
mas COTS: 

1. Ausencia jle control sobre la funcionalidady el rendimiento. Si bien la interfaz que 
presenta un producto puede parecer que oferte las facilidades requeridas, estas pueden 
no estar implementadas adecuadamente o pueden tener un pobre rendimiento. El pro- 
ducto puede tener operaciones ocultas que interfieran en su funcionamiento en una si- 
tuacion especifica. Resolver estos problemas debe ser una prioridad para el integrador 
del producto COTS, pero no es un problema que concierna al vendedor del producto. 
Los usuarios simplemente tienen que buscar la forma de sortear los problemas si quie- 
ren reulilizar el producto COTS. 

2. Problemas con la interoperabilidad del sistema COTS. Algunas veces es dificil obte- 
ner productos COTS que trabajen de forma conjunta debido a que cada producto se 
basa en sus propias suposiciones de como deberiautilizarse. Garlan y otros (Garlan et 
al., 1995) publicaron su experiencia en el intento de integracion de cuatro productos 
COTS, y observaron que tres de estos productos estaban basados en eventos, pero que 
cada uno usaba un modelo diferente de eventos, y consideraron que cada uno de di- 
chos modelos tenia acceso exclusivo a la cola de eventos. Como consecuencia, el pro- 
yecto requirio cinco veces mas esfuerzo que el que se predijo originalmente, y la 
agenda se prolongo durante dos aftos en lugar de los seis meses previstos. 
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3. No existe control sobre la evolution del sistema. Los vendedores de productos COT 
toman sus propias decisiones sobre los cambios en el sistema como respuesta a las pn 
siones del mercado. Concretamente, en productos para PCs se producen frecuente 
mente nuevas versiones y pueden no ser compatibles con todas las versiones anterii 
res. Las nuevas versiones pueden tener funcionalidades adicionales no deseadas, 
versiones previas pueden dejar de estar disponibles y no tener soporte. 

4. Soporte de los vendedores de productos COTS. El nivel de soporte disponible desc 
los vendedores de COTS es importante cuando surgen problemas debido a que 1( 
desarrolladores no tienen acceso al codigo fuente y a la documentacion detallada di 
sistema. Si bien los vendedores pueden comprometerse a proporcionar soporte, 1( 
cambios en el mercado y las circunstancias economicas pueden hacer que sea dific 
para ellos proporcionar dicho soporte. Por ejemplo, un vendedor de sistemas COT 
puede decidir no continuar vendiendo un producto debido a una escasa demanda 
puede ser absorbido por otra compania que no desea soportar todos sus productos ai 
tuales. 

Desde luego, no es probable que todos estos problemas ocurran en cada caso, pero al mi 
nos uno de ellos se va a produciren la mayoria de los proyectos de integracion de COTS. E 
consecuencia, los beneficios en coste y tiempo derivados de la reutilizacion de COTS son pn 
bablemente menores que los que podrian esperarse en un principio. 

Ademas, Boehm y Abts sefialan que, en muchos casos, el coste de mantenimiento y evi 
lucion de un sistema puede ser mayor cuando se utilizan productos COTS. Todas las dificu 
tades anteriores son problemas del ciclo de vida; no solo afectan al desarrollo inicial del si 
tema. En un sistema, cuantos menos desarrolladores originales haya, mas personas estar 
implicadas en su mantenimiento, por lo que es mas probable que se planteen problemas ci 
la integracion de productos COTS. 

A pesarde estos problemas, los beneficios de la reutilizacion de productos COTS son si 
nificativos debido a que estos sistemas ofrecen mucha mas funcionalidad a la persona q 
los reutiliza. Pueden ahorrarse meses y a veces anos de esfuerzo de implementacion si se re 
liliza un sistema existente y los tiempos de desarrollo del sistema se reducen drasticamen 
Por ejemplo, el sistema de adquisiciones descrito en la Figura 18.11 fue implementado y di 
plegado en una compania muy grande en nueve meses, mientras que originalmente se es 
maron tres anos para el desarrollo de un sistema nuevo. Si la entrega de un sistema de f< 
ma rapida es fundamental y se tiene alguna flexibilidad en los requerimientos, entonces 
integracion de productos COTS es amenudo la estrategia de reutilizacion mas efectiva a; 
guir. 

18.5.2 Lmeas de productos software 

Una de las aproximaciones mas efectivas para la reutilizacion es la creacion de lineas de pi 
ductos software o familias de aplicaciones. Una linea de productos es un conjunto de aplii 
ciones con una arquitectura comun especifica de dichas aplicaciones, tal y como se expuso 
el Capitulo 13. Cada aplicacion especifica se especializa de alguna manera. El micleo com 
de la familia de aplicaciones se reutiliza cada vez que se requiere una nueva aplicacion. El ni 
vo desarrollo puede implicar una configuracion especifica de componentes, implementaci 
de componentes adicionales y adaptacion de algunos componentes para satisfacer las nuei 
demandas. 
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Se pueden desarrollar varios tipos de especializacion de Hneas de productos software: 

1 . Especializacion de la plataforma. Se desarrollan versiones de la aplicacion para dife- 
rentes plataformas. Por ejemplo, pueden existir versiones de la aplicacion para plata- 
formas Windows, Solaris y Linux. En estecaso, la funcionalidadde la aplicacion nor- 
malmente no se cambia; solo se modifican aquellos componentes que interactuan con 
el hardware y con el sistema operativo. 

2. Especializacion del entorno. Se crean versiones de la aplicacion para gestionar entor- 
nos operativos y dispositivos perifericos concretos. Por ejemplo, un sistema para ser- 
vicios de emergencia puede existir en distintas versiones dependiendo del tipo de sis- 
tema de radio utilizado. En este caso, los componentes del sistema se cambian para 
reflejar la funcionalidad del equipo de comunicaciones utilizado. 

3. Especializacion de la funcionalidad. Se crean versiones de la aplicacion para clientes 
especificos que tienen diferentes requerimientos. Por ejemplo, un sistema automatico 
de biblioteca puede modificarse dependiendo de si es utilizado en una biblioteca pu- 
blica, una biblioteca privada o una biblioteca universitaria. En este caso, los compo- 
nentes que implementan la funcionalidad pueden ser modificados y se pueden afiadir 
nuevos componentes al sistema. 

4. Especializacion delproceso. El sistema se adapta para tratar con procesos de negocio 
especificos. Por ejemplo, un sistema de pedidos puede adaptarse en una compania para 
trabajar con un proceso de pedidos centralizado y con un proceso distribuido en otra. 

Las Hneas de productos software se disefian para ser reconfiguradas. Esta reconfiguracion 
puede implicar anadir o eliminar componentes del sistema, definirparametrosy restricciones 
para los componentes del sistema, e incluirconocimiento de los procesos de negocio. Las H- 
neas de productos software pueden ser configuradas en dos puntos del proceso de desarrollo: 

• Configuration durante el despliegue, en donde un sistema generico se disefia para su con- 
figuracion por un cliente o consultores que trabajan con el cliente. El conocimiento de 
los requerimientos especificos del cliente y el entorno del sistema operativo se incluye 
en un conjunto de ficheros de configuracion que son utilizados por el sistema generico. 

• Configuration durante el diseho, en donde la organizacion que esta desarrollando el soft- 
ware modifica un nucleo de Hneas de productos comunes desarrollando, seleccionando 
o adaptando componentes para crear un nuevo sistema para un cliente. 

La configuracion durante el despliegue es la aproximacion utilizada en paquetes de software 
verticales que son diseflados para una aplicacion especificatalcomoun sistema de gestionde 
informacion de un hospital. Tambien se utiliza en sistemas de Planificacion de Recursos de Em- 
presas (ERP) (O'Leary, 2000) tales como los producidos por SAP y B E A . Estos son sistemas 
integrados y a gran escala, que son diseflados para soportar procesos de negocio tales como pe- 
didos y facturacion, gestion de inventarios y planificacion de fabricacion. El proceso de confi- 
guracion para estos sistemas implica compartir la informacion detallada sobre el negocio del 
cliente y el proceso de negocio y a continuacion incluiresta informacion en una base de datos 
de configuraciones. Esto a menudo requiere el conocimiento detallado de las herramientas y 
notaciones de configuracion y normalmente se lleva a cabo por consultores que trabajan al lado 
de los clientes. La Figura 18.12 ilustra la organizacion de un sistema ERP . 

El sistema ERP generico incluye un gran numero de modulos que pueden componerse de 
diferentes formas para crear un sistema especifico. El proceso de configuracion implica elegir 
que modulos tienen que ser incluidos, configurar estos modulos individuals, definir procesos 
y reglas de negocio, y definir la estructura y organizacion de la base de datos del sistema. 
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Los sistemas ERP son quiza el ejemplo mas extendido de reutilizacion de software. La m 
yoria de las grandes companias utilizan estos sistemas para soportar alguna o todas sus fu 
ciones. Sin embargo, existe la limitacion obvia de que la funcionalidad del sistema se restrin 
a la funcionalidad del micleo generico. Ademas, las operaciones y procesos de una compafi 
tienen que expresarse en el lenguaje de configuracion del sistema, y puede haber una discr 
pancia entre los conceptos del negocio y los conceptos soportados en el lenguaje de config 
racion. Por ejemplo, en un sistema ERP que fue vendido a una universidad, el concepto de i 
cliente tuvo que ser definido. Esto provoco problemas reales debido a que las universidad 
tienen multiples tipos de clientes (estudiantes, agencias de investigacion, instituciones ed 
cativas, etc.) y ninguno de estos es comparable con un cliente comercial. Una seria discr 
pancia entre el modelo de negocio utilizado por el sistema y el modelo utilizado por el clie 
te hace que sea muy probable que el sistema ERP no satisfaga las necesidades reales d 
cliente (Scott, 1999). 

La aproximacion alternativa a la reutilizacion de familias de aplicaciones es la configui 
cion por el proveedor del sistema antes de entregarlo al cliente. El proveedor comienza o 
un sistema generico y a continuacion, modificando y extendiendo modulos en este sisterr 
crea un sistema especifico que proporciona las funcionalidades requeridas por el cliente. EI 
aproximacion normalmente implica cambiary extender el codigo fuente del nucleo del sisl 
ma para que sea posible una mayor flexibilidad que con una configuracion durante el dt 
pliegue. 

Las lineas de productos software normalmente surgen a partir de aplicaciones existenh 
Es decir, una organizacion desarrolla una aplicacion y, cuando se requiere una nueva aplic 
cion, se utiliza laprimeracomo base para la nueva aplicacion. Posteriores demandas de ni 
vas aplicaciones hacen que el proceso continue. Sin embargo, debido a que los cambios tie 
den a degradar la estructura de la aplicacion, en algun momenta debe tomarse alguna decisi 
especifica para disenar una linea de productos generica. El diseno se basa en la reutilizaci 
del conocimiento adquirido a partir del desarrollo del conjunto inicial de aplicaciones. 

Se puede pensar en las lineas de productos software como jnstanc iacionesy especialii 
ciones de arquitecturas de aplicaciones mas genericas, tal y como se explico en el Capiu 
13. Una arquitectura de aplicaciones es muy general; las lineas de productos software esr. 
cializan la arquitectura paraun tipo concrete de aplicacion. Por ejemplo, consideremos un s 
tema de lineas de productos disenado para gestionar el uso de un vehiculo para servicios 
emergencia. Los operadores de este sistema recogen llamadas sobre incidentes ocurridos, t 
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cuentran el vehiculo adecuado para responder al incidentey envian el vehiculo al lugardel in- 
cidente. Los desarrolladores de un sistema como este pueden comercializar versiones de di- 
cho sistema para servicios de policia, de bomberos y de ambulancia. 

Este sistema de gestion de vehiculos es un ejemplo de un sistema de gestion de recursos 
cuya arquitectura de las aplicaciones se muestra en la Figura 18. 13. Puede verse como se ins- 
tancia esta estructura de cuatro capas en la Figura 18.14, que muestra los modulos que podri- 
an incluirse en una linea de productos de sistemas de gestion de vehiculos. Los componentes 
en cada nivel de la linea de productos son los siguientes: 

1 . En el nivel de interfaz de usuario, hay componentes que proporcionan una interfaz de 
la pantalla del operadory una interfaz con el sistema de comunicaciones utilizado. 

2. En el nivel de E/S (nivel 2), hay componentes que gestionan la autenticacion del ope- 
rador, generan informes de incidentes y vehiculos enviados, soportan la generacion de 
mapas y planificacion de ratas, y proporcionan un mecanismo para los operadores para 
realizar consultas a las bases de datos del sistema. 



, . , , Interfaz de comunicaciones 

Interfaz de usuario , , . . 

del sistema 



gura 18.14 

quitectura de linea 
\ productos de un 
j tenia de gestion 
* vehiculos. 
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Planrficacion de Generador 
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3. En el nivel de gestion de recursos (nivel 3), hay componentes que permiten localiz 
y enviar los vehiculos al lugardel incidente, componentes que actualizan el estado t 
los vehiculos y del equipamiento, y un componente para registrar los detalles de li 
incidentes. 

4. En el nivel de base de datos, ademas del soporte usual para la gestion de transacci*] 
nes, hay bases de datos independientes de vehiculos, equipamiento y mapas. 

Para crear una version especifica de este sistema, se puede tener que modificar comd 
nentes individuales. Porejemplo, lapoliciatiene un gran numero de vehiculos peropocos i 
pos de vehiculos, mientras que el servicio de incendios tiene muchos tipos de vehiculos ei 
pecializados; por lo tanto, puede ser necesario incorporar al sistema una estructura diferen| 
de base de datos de vehiculos. 

La Figura 18.15 muestra los pasos comprendidos en la adaptacion de una familia ( 
aplicaciones para crear una nueva aplicacion. Los pasos implicados en este proceso g 
neral son: 

1. EUcitacion de los requerimientos de los stakeholders. Se puede empezar con un pn 
ceso normal de ingenieria de requerimientos. Sin embargo, debido a que un sisten 
ya existe, se necesitara probar y experimentar con ese sistema, expresando sus requ 
rimientos como modificaciones para las funciones ya proporcionadas. 

2 . Elegir un miembro adecuado de la familia. Se analizan los requerimientos y se eli j 
el miembro de la familia que mas se adecue a los requerimientos para su modificacio 
Este no necesita ser el sistema que fue probado. 

3 . Renegociar los requerimientos. A medida que surgen mas detalles de cambios requj 
ridos y se planifica el proyecto, puede haber alguna renegociacion de requerimienu 
para minimizar los cambios que se necesitan. 

4. Adaptar el sistema existente. Se desarrollan nuevos modulos para el sistema existe] 
te, y los modulos del sistema existente se adaptan para satisfacer los nuevos reque A 
mientos. 

5 . Entregar el nuevo miembro de la familia. La nueva instancia de la linea de product 
se entrega al cliente. En esta etapa, se deberian documentar sus caracteristicas claj 
para que pueda utilizarse como base para otros desarrollos futuros de sistemas. 

Cuando se crea un nuevo miembro de una familia de aplicaciones, se puede tener que bu 1 
car un equilibrio entre reutilizar la aplicacion generica tanto como sea posible y satisfacer h 
requerimientos detallados de los stakeholders. Cuanto mas detallados sean los requerirme 
tos del sistema, es menos probable que existan componentes que satisfagan dichos requei 
mientos. Sin embargo, si los stakeholders estan dispuestos a ser flexibles y a limitar las mi 
dificaciones requeridas del sistema, normalmente se entregara el sistema mas rapidamente 
con un menor coste. 




Figura 18.15 Desarrollo de una instancia de un producto. 
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En general, el desarrollo de aplicaciones adaptando una version generica de la aplicacion 
significa que una proporcion muy elevada del codigo de la aplicacion es reutilizada. Ademas, 
la experiencia de aplicaciones es a menudo transferible de un sistema a otro, de forma que 
cuando los ingenieros software se incorporan a un equipo de desarrollo, su proceso de apren- 
dizaje se reduce. Las pruebas se simplifican debido a que las pruebas para partes grandes de 
la aplicacion tambien pueden ser reutilizadas, reduciendo asi el tiempo total del desarrollo de 
la aplicacion. 



PUNTOS CLAVE 

- Las ventafas de la reutiUzacion del software son castes mas bajos, desarrollo det software mas rapido y me- 
nores rlesgos. la confiabilidad del sistema se ircrementa y los especialistas pueden ser utilizados de forma 
mas efectiva axiccnlrando su experiencia en et diseno de componcntcs rcutiUzaUcs. 

• Los patrones de diseno 500 abstracciones de alto nivel que docLuncntan soluciones de diseflo exitosas. Son 
lundamentales para reutiuzaf el dfseflb en el desanolo orientado a objetos. Una description del patron de- 
ben'a incluir un nombte del patron, una descripcion del problema y ta solution, y una declaration de los re- 
siitados y compiDmisos ai utilizar el patron. 

• Los gene redores de progiames son una aproximacion altcmativa al concepto de rcutnlzacton en donde los 
conceptos reutrHzabies estan embebidos en un sistema gencrador. El disenador especifica tas abstracciones 
requeridas utilizando un lenguaje especifico del domiirio, y se genera un programa ejecutable. 

• Los matcos de trabajo son cotecdones de objetos concretos y abstractos que se disenan para ser laulBiadov 
medante ta espedaHzacion y ta adicion de nuevos objetos. 

• La reutilizacion de productos CDIS esta rclacionada con la reutiUzacion a gtan escala de Ids sistemas comer- 
dales. Estos proporaonan bastante njndonaUdad y su reutJttzacion puede reducir tas costes y tiempo de des- 
airollo de forma radical. 

• LflS problemas potenciales con la «utilizacion basada en COTS Incluyen la ausencia de control sobre ta tun- 
cionalidad y et raidimiaitcf ausencia de control sobre la evolucion de los sistemas, ta neccsidad de soporte 
de vendedores extemos y dilicultadcs para asegurar que tos sistemas pueden irrteroperar. 

• Los sistemas <b Planificacion dc Rccursos de Bnprcsa son usctdos de iorma muy extensa. Se crcan sistemas 
IRP especificos configurando*» sistema generico en tiempo de dcsplicguc con irrformadori sobue el negocio 
deldente. 

• las imeas de prDcluctos software son aplicaciones relacionadas que se desarrollan a partir de una o masapti- 
cadones base. Un sistema generico se adapta y especializa para satislacer rcciuerimicntos especificos de tuo- 
donalidades, platafonna de destino o configuracion de fiuxionamiaito. 



IECTURAS ADICIONALES 



Reuse-based Software Engineering. Un estudio claro de diferentes aproximaciones para la reutilizacion del softwa- 
re. Los autores tratan cuestiones tecnicas de la reutilizacion y procesos de gestion de reutilizacion. (H. Mili er ai, 
2002, )ohn Wiley & Sons.) 
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«A Lifecycle Process for the effective reuse of commercial off-the-shelf software". Esta es una buena introducciol 
general, que estudia las ventajas y desventajas de utilizar COTS en ingenieria del software. (C. L. Braun, Proa 
Symposium on Software Reusability, Los Angeles, 1999. ACM Press. Disponible desde (a Libreria Digital ACM.) 

Design Patterns: Elements of Reusable Object-oriented Software. Esta es la guia de referenda original de patrond 
software que introdujo este concepto a una comunidad amplia. (E. Gamma etai, 1995, Addison-Wesley.) 

« Aspect-oriented programming". Este numeroespecialdela CACM tiene varios articulos sobre el desarrollo de sofl 
ware orientado a aspectos. Es un excelente punto de partida para leer sobre este tema. [Comm. ACM, 44(10), octij 
bre de 2001.] 



EJERCICIOS 



18.1 tCuales son los principales factores tecnicos y no tecnicos que impiden la reutilizacion de software? 4U: 
ted reutiliza mucho software?, y si no lo hace, ipor que? 

182 Sugiera por que los ahorros de costes al reutilizar software existente no son simplemente proporcionale 
al tamaho de los componentes que son reutilizados. 

18.3 De cuatro circunstancias en que usted podria no recomendar la reutilizacion de software. 

1&4 t Por q ue los patrones son una forma efectiva de reutilizacion para el cliseno? <,Cuales son las desventaja 
deesta aproximacion para la reutilizacion? 

18.5 Ademas de los dominios de aplicaciones discutidos aqui sugiera otros dos dominios en donde la reutii 
zacion basadaen un generador podria tener exito. Explique por que piensa que esta aproximacion para | 
reutilizacion sera rentable en estos dominios. 

18.6 Explique por que se necesitan normalmente adaptadores cuando los sistemas se construyen integrand, 
productos COTS, 

18.7 Identifique seis posibles riesgos que pueden tener lugar cuando los sistemas se construyen utilizarte) 
COTS. cQue pasos puede seguir una compama para reducir estos riesgos? 

188 Utilizando una arquitectura general de un sistema de informacion (descrita en el Capitulo 13) como pun! 
de partida, disehe una familia de aplicaciones de sistemas de informacion que podria utilizarse en biblj<] 
tecas de Mbros, peliculas, musica y recortes de periodico. 

18.9 Utilizando el ejemplo del sistema de estacidn meteorologica descrito en el Capitulo 14, sugiera una arqii 
tectura para una familia de aplicaciones que este relacionada con la monitorizacion remota y la recolel 
cion de datos. 

18.10 La reutilizacion de software trae consigo varias cuestiones sobre derechos de autor y propiedad intele 
tual. Si un cliente paga a un proveedor de software para desarrollar un sistema, ^quien tiene el derecr 
de reutilizacion del codigo desarrollado? £EI proveedor de software tiene derecho de utilizar ese codig 
como base para un componente generico? iQue mecanismos de pago podrian utilizarse para reembolsi 
a los proveedores de componentes reutilizables? Comente estas y otras cuestiones eticas asociadas a 
reutilizacion de software. 



Ingeniena del software 
basada en componentes 



Objetivos 

El objetivo de este capitulo es describirun proceso de desarrollo 
del software basado en la composicion de componentes 
reutilizablesy estandarizados. Cuando haya leido este capitulo: 

• conocera que la ingeniena del software basada en 
componentes esta relacionada con el desarrollo de 
componentes estandarizados basados en un modelo de 
componentes y la composicion de estos en sistemas de 
aplicaciones; 

• comprendera el concepto de componente y modelo de 
componentes; 

• conocera las principales actividades en el proceso CBSE y 
comprendera por que tiene que llegar a un compromiso con 
los requerimientos para que los componentes puedan ser 
reutilizados; 

• comprendera algunas de las dificultades y problemas que 
tienen lugar durante el proceso de composicion de 
componentes. 

Contenidos 

19.1 Componentes y modelos de componentes 

19.2 El proceso CBSE 

19.3 Composicion de componentes 
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Tal y como se sugirio en el Capitulo 18, la ingenieria del software basada en reutilizacion s 
estaconvirtiendo en la principal aproximacion de desarrollo para sistemas comerciales y d 
empresas. Las entidades que son reutilizadas varian desde funciones de grano fino hasta sis 
temas enteros de aplicaciones. Sin embargo, hasta hace relativamente poco, ha sido dificil ri 
utilizar componentes de programas de grano medio. Los componentes de grano medio so 
significativamente mas grandes que los objetos individuales o procedimientos, con mas fur 
cionalidad, aunque son mas pequefios y mas especificos que los sistemas de aplicacion. Afoi 
Lunadamente, los desarrollos estandarizados promovidos por los principales vendedores d 
software han dado lugar actualmente a que los componentes puedan interoperax dentro de u 
marco de trabajo como CORBA. Este ha abierto oportunidades para la reutilizacion sistemi 
tica a traves de la ingenieria del software basada en componentes. 

La ingenieria del software basada en componentes (CBSE) surgio a finales de los 90 com 
una aproximacion basada en reutilizacion al desarrollo de sistemas software. Su creacion fu 
motivadapor la frustracion de los disenadores de que el desarrollo orientado a objetos no ri 
conducido a una reutilizacion extensiva, tal y como se sugirio originalmente. Las clases de ot 
jetos simples eran demasiado detalladas y especificas, y a menudo tenian que serenlazada 
con aplicaciones en tiempo de compilacion. Habia que tener un conocimiento detallado de \£ 
clases para usarlas, lo cual generalmente significaba que habia que tener acceso al codigl 
fuente del componente. Esto hizo que fuera dificil el marketing de objetos como componer 
tes reutilizables. A pesarde las predicciones optimistas iniciales, nunca se desarrollo un me 
cado significativo para objetos individuales. 

C B S E es el proceso de definir, implementar e integrar o componer en sistemas compi 
nentes independientes debilmente acoplados. Se haconvertido en una importante aproximj 
cion de desarrollo del software debido a que los sistemas software son cada vez mas grande 
y mas complejos y los clientes demandan software mas confiable que sea desarrollado m; 
rapidamente. La unica forma en la que podemos tratar con la complejidad y entregar mej< 
software mas rapidamente es reutilizar componentes software en vez de reimplementarlos. 

Los fundamentos de la ingenieria del software basada en componentes son: 

1 . Componentes independientes, que son completamente especificados por sus interf 
ees. Deberia haberuna clara separacion entre la interfaz de los componentes y su in 
plementacion para que una implementacion de un componente pueda reemplazar 
por otro sin cambiar el sistema. 

2. Estdndares de componentes, que facilitan la integracion de los componentes. Estos e 
tandares se incluyen en un modelo de componentes y definen, en el nivel mas baj 
como las interfaces de componentes deberian especificarse y como se comunican 1( 
componentes. Algunos modelos definen interfaces que deberian implementarse coi 
forme a todos los componentes. Si los componentes cumplen con los estandares, ei 
tonces su funcionamiento es independiente de su lenguaje de programacion. Los cor 
ponentes escritos en diferentes lenguajes pueden integrarse en el mismo sistema. 

3 . El middleware, que proporciona soportes software para la integracion de compone 
tes. Para conseguir que componentes independientes y distribuidos trabajenjuntos, 
necesita un soporte middleware que maneje las comunicaciones de los componente 
Unproducto middleware como CORBA (Pope, 1998), tratado en el Capitulo 12, m 
neja cuestiones de bajo nivel de forma eficiente y permite al disenador centrarse < 
problemas relacionados con la aplicacion. Ademas, un producto middleware utiliz 
do para implementar un modelo de componentes puede proporcionar soporte pa 
asignacion de recursos, gestion de transacciones, seguridad y concurrencia. 
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4. Un proceso de desarrollo, que se adapta a la ingeniena del software basada en com- 
ponentes. Si se intenta anadir una aproximacion basada en componentes a un proceso 
de desarrollo que esta adaptado a la produccion de software original, se puede obser- 
var que las suposiciones inherentes al proceso limitan el potencial del C B S E . Los pro- 
cesos de desarrollo CBSE se analizan en la Seccion 19.2. 

El desarrollo basado en componentes se esta adoptando cada vez mas como una aproxi- 
macion fundamental a la ingeniena del software incluso aunque los componentes reutiliza- 
bles no esten disponibles. CBSE esta asentado sobre unos principios de diseno so lidos que so- 
portan la construccion de software comprensible y mantenible. Los componentes son 
independientes para que no interfieran en su funcionamiento unos con otros. Los detalles de 
implementacion se ocultan, por lo que la implementacion de los componentes puede cam- 
biarse sin afectar al resto del sistema. Los componentes se comunican a traves de interfaces 
bien definidas, de forma que si estas interfaces se mantienen, un componente puede reem- 
plazarse porotro que proporcione una funcionalidad adicional o mejorada. Ademas, las in- 
fraestructuras de componentes proporcionan plataformas de alto nivel que reducen los costes 
del desarrollo de aplicaciones. 

Aunque CBSE se esta convirtiendo en una aproximacion fundamental para el desarrollo 
del software, presenta varios problemas: 

1 . Confiabilidad de los componentes. Los componentes son cajas negras de unidades de 
programas, y el codigo de los componentes puede no estar disponible para los usua- 
rios de dichos componentes. En tales casos, ^como sabe un usuario que un compo- 
nente es confiable? El componente puede no tener documentados modos de fallo que 
comprometen el sistema en el que se utiliza dicho componente. Su comportamiento 
no funcional puede no ser el esperado, y un problema mas grave es que el componen- 
te podria ser un caballo de Troya que oculta codigo danino que viola la seguridad del 
sistema. 

2. Certification de componentes. Estrechamente relacionada con la confiabilidad se ha- 
11a la cuestion de la certificacion. Se ha propuesto que asesores independientes debe- 
rian certificar los componentes para asegurar a los usuarios que los componentes son 
confiables. Sin embargo, no esta claro como se puede hacer esto. ^Quien pagaria por 
la certificacion?, ^quien seria responsable si el componente no funciona de acuerdo 
con la certificacion?, y ^como podrian los certificadores limitar su responsabilidad? 
Desde nuestro punto de vista, la unica solucion viable es certificar que los compo- 
nentes cumplen una especificacion formal. Sin embargo, la industria no parece dis- 
puesta a pagar por esto. 

3. Prediction de propiedades emergentes. Tal y como se explico en el Capitulo 2, todos 
los sistemas tienen propiedades emergentes, y el intentar predecir y controlar estas 
propiedades emergentes es importante en el proceso de desarrollo del sistema. De- 
bido a que los componentes son opacos, predecir sus propiedades emergentes es 
particularmente dificil. Como consecuencia, es posible encontrarse con que, cuando 
se integran componentes, el sistema resultante tiene propiedades no deseadas que 1 i - 
mitan su uso. 

4. Equilibrio de requerimientos. Normalmente se tiene que encontrar un equilibrio entre 
los requerimientos ideales y los componentes disponibles en el proceso de especifica- 
cion y diseno del sistema. Por el momento, alcanzareste equilibrio es un proceso in- 
tuitivo. Necesitamos un metodo de analisis de equilibrio sistematico y mas estructu- 
rado para ayudar a los disenadores a seleccionar y configurar componentes. 
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Hasta ahora, el principal uso de CBSE ha sido la construccion de sistemas de informacio 
de empresas, tales como sistemas de comercio electronico. Los componentes que se reutil 
zan son desarrollados internamente o se obtienen de proveedores conocidos de confianzi 
Aunque algunos vendedores venden componentes online, la mayoria de las compaflias son t( 
davia reticentes a confiar componentes binarios obtenidos de forma externa. No es probabl 
que la vision completa de C B S E con proveedores de componentes especializados tenga lugj 
hasta que estos problemas que hemos mencionado puedan ser resueltos. 

19.1 Componentes y modelos de componentes 

Hay un consenso general en la comunidad de que un componente es una unidad de softwai 
independiente que puede estar compuesta por otros componentes y que se utiliza para ere; 
un sistema software. Aparte de esto, sin embargo, distintas personas han propuesto defin 
cionesdeun componente software. Councilly Heineman (Councilly Heineman, 2001) def 
nen un componente como : 

Un elemento software que seajusta a un modelo de componentes y que puede ser des- 
plegadoy compuesto de forma independiente sin modification segun un estdndar de 
composition. 

Esta definicion se basa fundamentalmente en estandares — una unidad software que j 
ajusta a estos estandares es un componente — . Szyperski (Szyperski, 2002), sin embargo, r 
menciona los estandares en su definicion de componente, sino que, en vez de eso. se centi 
en las caracteristicas clave de los componentes: 

Un componente software es una unidad de composition con interfaces especificadas 
contractualmente y dependencias de contexto explicitas unicamente. Un componente 
software puede ser desplegado de forma independiente y esta sujeto a la composition 
por terceras partes. 

Szyperski tambien constata que un componente no tiene un estado externamente observ 
ble. Esto significaque las copias de componentes son indistinguibles. Sin embargo, algum 
modelos de componentes, como el modelo Enterprise Java Beans, permite componentes ce 
estado, lo que claramente no se corresponde con la definicion de componente de Szypersl 
Mientras que los componentes sin estado son ciertamente mas sencillos de usar, consider 
mos que CB SE deberia acomodarse tanto a los componentes con estado como a los comp 
nentes sin estado. 

Lo que tienen en comun estas definiciones es que estan de acuerdo en que los compone 
tes son independientes y que son unidades de composicion fundamentales en un sistema. De 
de nuestro punto de vista, una definicion completa de componente puede derivarse desde ar 
bas propuestas. La Figura 19.1 muestra lo que puede considerarse que son caracteristic 
esenciales de un componente para ser usado en C B S E . 

Estas definiciones formales de componentes son bastante abstractas y no proporcion; 
realmente una idea clara de lo que hace un componente. Una de las formas mas utiles de co 
siderar un componente es como un proveedor de servicios independiente. Cuando un sisten 
necesita algiin servicio, llama a un componente para proporcionar dicho servicio sin tener < 
cuenta donde se esta ejecutando el componente o que lenguaje se ha utilizado para desarr 
liar el componente. Por ejemplo, un componente en un sistema de biblioteca proporciona i 
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Caracteristkas 

del componente Description 



Estandartzado La estandarizaci6n de componentes signifies que un componente 

usado en un praceso CBSE tiene que ajustarse a algun modelo 
estandartzado de componentes. Este modelo puede definif interfaces 
de componentes, metadatos de componentes, documentation, 
composici6n y despliegue. 

Independiente Un componente deberfa ser independiente, deberfa ser posible 

componerio y desplegarlo sin tener que utiltzar otros componentes 
espedfkos. En las situaciones en las que el componente necesita 
servicios proporcionados externa mente, estos deberfan haoerse 
explkitos en una espectfkaci6n de interfaz del tipo «requiere». 

Componible Para que un componente sea componible, todas las interaction es 

extemas deben tener lugar a traves de interfaces definidas 
publicamente. Ad em 4s debe proporcionar acceso extemo a la 
informacidn sobre si mismo, como por ejemplo a sus metodos y 
atnbutos. 



igura 19.1 
aracteristicas de 
Dmponentes. 



Desplegable Para ser desplegable, un componente debe ser independiente y debe 

ser capaz de hmctonar como una entidad autonoma o sobre una 
plataforma de componentes que impEemente el modelo de 
componentes. Esto normalmente significa que el componente es 
btnario y que no tiene que compilarse antes de ser desplegado. 

Documentado Los componentes tienen que estar comptetamente documentados para 
que tos usuarios potenciales puedan decidir si los componentes 
satisfacen o no sus necesidades. La sintaxis e, idealmente, la semantka 
de todas las interfaces de componentes tienen que ser especrficadas. 



servicio de busqueda que permite a los usuarios buscar diferentes catalogos de bibliotecas; un 
componente que convierta de un formato grafico a otro (por ejemplo. TIFF a JPEG) propor- 
ciona un servicio de conversion de datos. 

La vision de un componente como un proveedor de servicios resalta dos caracteristicas cri- 
ticas de un componente reutilizable: 

1. El componente es una entidad ejecutable independiente. El codigo fuente no esta dis- 
ponible, por lo que el componente no tiene que ser compilado antes de que sea usado 
con otros componentes del sistema. 

2. Los servicios ofertados por un componente estan disponibles a traves de una inter- 
faz, y todas las interacciones son a traves de esa interfaz. La interfaz del componen- 
te se expresa en terminos de operaciones parametrizadas y su estado interno nunca se 
muestra. 

Los componentes se definen por sus interfaces y, en los casos mas generales, puede con- 
siderarse que tienen dos interfaces relacionadas, tal y como se muestra en la Figura 19.2. 

1 . Una interfaz proporciona, que define los servicios proporcionados por el componen- 
te. La interfaz que hemos denominado proporciona, fundamentalmente, es el API del 
componente. Define los metodos que pueden ser llamados porun usuario del compo- 
nente. Las interfaces proporciona se indican con un circulo al final de una linea desde 
el icono del componente. 
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Figura 19.2 
Interfaces de 
componentes. 



Interfax requiere 

Define los servicios 
que utiliza de los 
componentes } 
del entorno 




Interfaz proporciona 

O Define los servicios 

O proporcionados 

■Q por el componente 

,q a otros compuestos 



2. Una interfaz requiere, que especifica que servicios deben ser proporcionados porotro 
componentes en el sistema. Si estos no estan disponibles, entonces el componente n> 
funcionara. Esto no compromete la independenciao el despliegue del componente de 
bido a que no se requiere el uso de un componente especifico para proporcionar di 
chos servicios. Las interfaces requiere se indican con un semicirculo al final de una li 
nea desde el icono de componentes. 

Por ejemplo, la Figura 19.3 muestra un modelo de un componente que ha sido disenad' 
pararecopilary comparar informacionde un vector de sensores. Se ejecutade forma autonc 
ma para recoger datos durante un periodo de tiempo, y proporciona bajo demanda la compa 
racion de los datos a otro componente. La interfaz proporciona incluye metodos para anadii 
eliminar, iniciar, parar y probar los sensores. Tambien incluye metodos para informes (repoi 
y listAll) que informan sobre los datos recopilados y la configuracion de los sensores. Aunqu 
no se ha mostrado esto aqui, estos metodos naturalmente tienen asociados parametros que es 
pecifican la localizacion de los sensores y otra informacion. 

El componente de recopilacion de datos requiere que los sensores proporcionen una intet 
faz de gestion y una interfaz de datos. Estos tienen parametros que especifican el funciona 
miento y los datos que hay que recopilar. Se ha disenado de forma deliberada la interfaz re 
queridapara que no incluya operaciones especificas tales como Test. La interfaz requiere, ma 
abstracta, permite al componente de recopilacion de datos utilizarse con sensores con dife 
rentes interfaces. Un componente adaptador se utiliza como una interfaz entre el recopilado! 
de datos y el interfaz hardware especifico del sensor. 

Las clases de objetos tienen metodos asociados que son claramente similares a los mete 
dos definidos en las interfaces de componentes. ^Cual es, entonces, la distincion entre corr 
ponentes y objetos? Los componentes se desarrollan normalmente utilizando una aproxime 
cion orientada a objetos, pero difieren de los objetos en varios aspectos importantes: 

1 . Los componentes son entidades desplegarles. Es decir, no soncompilados enunprc 
grama de aplicacion, sino que se instalan directamente sobre una plataforma de eje 
cucion. Los metodos y atributos definidos en sus interfaces pueden ser accedidos pe 
otros componentes. 
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2. Los componentes no definen tipos. Una definicion de clase define un tipo abstracto de 
datos y los objetos son instancias de ese tipo. Un componente es una instancia, no una 
plantilla que se utiliza para definir una instancia. 

3. Las implementaciones de los componentes son opacas. Los componentes estan, al me- 
nos en principio, completamente definidos por la especificacion de su interfaz. La im- 
plementacion esta oculta para los usuarios de los componentes. Los componentes a 
menudo se entregan como unidades binarias de forma que el comprador no tiene ac- 
ceso a la implementacion. 

4. Los componentes son independientes del lenguaje. Las clases de objetos tienen que se- 
guir las reglas de un lenguaje de programacion orientado a objetos particular y, gene- 
ralmente, solo pueden interoperar con otras clases escritas en dicho lenguaje. Si bien 

los componentes se implementan normalmente utilizando lenguajes orientados a ob- 
jetos tales como Java, pueden implementarse en lenguajes de programacion no orien- 
tados a objetos. 

5. Los componentes estan estandarizados. A diferencia de las clases de objetos que pue- 
den implementarse de cualquier forma, los componentes deben ajustarse a algun mo- 
delo de componentes que restringe su implementacion. 

19.1.1 Modelos de componentes 

Un modelo de componentes es una definicion de los estandares para la definicion de compo- 
nentes, documentaciony despliegue. Estos estandares son utilizados por los desarrolladores 
de componentes para asegurar que los componentes puedan interoperar. Tambien son utiliza- 
dos por los proveedores de infraestructuras de comunicacion de los componentes, quienes pro- 
porcionan middleware para soportar el funcionamiento de estos. Se han propuesto muchos 
modelos de componentes, pero los modelos mas importantes son el modelo de componentes 
CORBA de OMG, el modelo Enterprise Java Beans de Sun y el modelo COM+ de Microsoft 
(Blevins, 2001; Ewald, 2001; Wang et al, 2001). 

Las tecnologias de infraestructura especificas tales como COM+ y EJB que se utilizan en 
CBSE son muy complejas. Como consecuencia, es dificil describir estas tecnologias sin ha- 
cer referencia a una gran cantidad de detalles de implementacion sobre los supuestos que sub- 
yacen en cada aproximacion y las interfaces utilizadas. En lugar de entrar en estos detalles 
aqui, nos centramos en los elementos fundamentales de los modelos de componentes. 

Los elementos basicos de un modelo de componentes ideal son analizados por Weinreich 
y Sametinger (Weinreich y Sametinger, 2001). Estos elementos del modelo se resumen en la 
Figura 19.4. Este diagrama muestra que los elementos en un modelo de componentes pueden 
clasificarse como elementos relacionados con las interfaces de los componentes, elementos 
relacionados con la informacion que se necesitaparautilizar el componente en un programa 
y elementos relacionados con el despliegue del componente. 

Los elementos que definen a un componente son sus interfaces. El modelo de componen- 
tes especifica como deberian definirse las interfaces y los elementos, tales como nombres de 
operaciones, parametros y excepciones, que deberian incluirse en la definicion de una inter- 
faz. El modelo tambien deberia especificar el lenguaje utilizado para definir las interfaces (el 
IDL). En CORBA y COM+, existe un lenguaje de definicion de interfaces especifico; EJB es 
especifico de Java, por lo que Java se utiliza como IDL. Algunos modelos de componentes 
requieren interfaces especificas que deben ser definidas por un componente. Estas se utilizan 
para integrar el componente con la infraestructura del modelo de componentes que propor- 
ciona servicios estandarizados tales como seguridad y gestion de transacciones. 
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Para que los componentes puedan distribuirse y ser accedidos de forma remota, necesitan 
tener un nombre o manejador unico asociado a ellos. En COM+, este es un identificador lini- 
co de 128 bits. En el modelo de componentes CORB A y en EJB,esun nombre jerarquico con 
una raiz basado en un nombre de dominio de Internet. Los metadatos de componentes son da- 
tes sobre el mismo componente, tales como informacion sobre sus interfaces y atributos. Los 
metadatos son importantes para que los usuarios del componente puedan encontrar que ser- 
vicios se proporcionan y cuales se requieren. Las implementaciones del modelo de compo- 
nentes normalmente incluyen formas especificas (como el uso de una interfaz de reflexion en 
Java) para acceder a estos metadatos del componente. 

Los componentes son entidades genericas y, cuando son desplegados, tienen que ser confi- 
gurados para su entorno de aplicacion particular. Por ejemplo, el componente Recopilacionde 
datos mostrado en la Figura 19.3 podria ser configurado con el maximo numero de sensores 
en un vector de sensores. Por lo tanto, el modelo de componentes deberia especificar como pue- 
den configurarse los componentes binarios para un entorno de despliegue particular. 

Una parte importante de un modelo de componentes es una definicion de como los com- 
ponentes deberian empaquetarse para su despliegue como entidades ejecutables indepen- 
dientes. Debido a que los componentes son entidades independientes, tienen que ser empa- 
quetadas con el resto de los elementos que no son proporcionados por la infraestructura del 
componente o no estan definidos en una interfaz requiere. La informacion de despliegue in- 
cluye informacion sobre los contenidos de un paquete y su organizacion binaria. 

Inevitablemente, a medida que surgen nuevos requerimientos, los componentes tendran 
que sercambiados o reemplazados. Por lo tanto, el modelo de componentes deberia incluir 
reglas para regular cuando y como se permite el reemplazo de componentes. Finalmente, el 
modelo de componentes deberia definir la documentacion asociada a los componentes. Esta 
se utiliza para encontrar el componente y decidir si es adecuado o no. 

Los modelosde componentes no son solo estandares; son tambien la base para el middle- 
ware de sistemas que proporciona el soporte para los componentes ejecutables. Weinreich y 
Sametinger (Weinreich y Sametinger, 2001) utilizan la analogia de un sistema operativo para 
explicar los modelos de componentes. Un sistema operativo proporciona un conjunto de ser- 
vicios genericos que pueden utilizarse por las aplicaciones. Una implementacion de un mo- 
delo de componentes proporciona servicios compartidos comparables para los componentes. 
La Figura 19.5 muestra algunos de los servicios que pueden ser proporcionados por una im- 
plementacion de un modelo de componentes. 

Los servicios proporcionados por la implementacion de un modelo de componentes pue- 
den perteneceradoscategorias: 
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1. Servicios Je plataforma. Estos servicios fundamentales permiten a los componentes 
comunicarse entre si. C O RB A es un ejemplo de una plataforma de modelos de com- 
ponentes. Los servicios de plataforma se describen en el Capitulo 12. 

2. Servicios horizontales. Estos servicios independientes de la aplicacion es probable que 
sean usados por muchos componentes diferentes. La disponibilidad de estos servicios 
reduce los costes del desarrollo de componentes e implica que pueden evitarse in- 
compatibilidades potenciales de componentes. 

Para hacer uso de los servicios proporcionados por una infraestructura de modelos de 
componentes, los componentes se despliegan en un contenedor estandarizado predefinido. Un 
contenedor es un conjunto de interfaces utilizadas para acceder a las implementaciones de los 
servicios de soporte. La inclusion del componente enelcontenedorproporcionaautomatica- 
mente el acceso a los servicios. Las interfaces del componente en si mismas no son accesi- 
bles directamente por otros componentes; tienen que ser accedidas a traves del contenedor. 



19.1.2 Desarrollo de componentes para reutlllzaclon 

La vision a largo plazo de CBSE es que habra proveedores de componentes cuyos negocios 
se basen en el desarrollo y venta de componentes reutilizables. Como ya se ha indicado, los 
problemas de confianza implican que hasta ahora no haya sido desarrollado un mercado abier- 
to de componentes, y la mayoria de los componentes que son reutilizados han sido desarro- 
llados dentro de la empresa. Los componentes reutilizables no estan especialmente desarro- 
llados, sino que se basan en componentes existentes que ya han sido implementados y 
utilizados en sistemas de aplicaciones. 

En general, los componentes desarrollados internamente no son inmediatamente reutiliza- 
bles. Incluyen caracteristicas especificas de la aplicacion e interfaces que son poco probables 
que sean requeridas en otras aplicaciones. Por consiguiente, hay que adaptar y extender estos 
componentes para crear una version masgenericay por lo tanto mas reutilizable. Obviamen- 
te esto tiene un coste asociado. Usted tiene que decidir, en primer lugar, si un componente va 
a ser probablemente reutilizado y en segundo lugar, si el ahorro de costes de la reutilizacion 
justifican los costes para hacer que ese componente sea reutilizable. 

Para responder a la primera de estas cuestiones, tiene que decidirse si el componente im- 
plementa una o mas abstracciones del dominio estables. Las abstracciones del dominio esta- 
bles son conceptos fundamentales en el dominio de aplicaciones que cambian muy lenta- 
mente. Por ejemplo, en un sistema bancario, las abstracciones del dominio podrian incluir 
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cuentas, depositos de cuentas y extractos. En un sistema de gestion de un hospital, las abs- 
tracciones del dominio podrian incluir pacientes, tratamientos y enfermeras. Estas abstrac- 
ciones del dominio se denominan a veces objetos de empresa. Si el componente es una im- 
plementacion de un objeto de empresa o grupo de objetos relacionados utilizados con 
frecuencia, probablemente pueden ser reutilizados. 

Para responder a la cuestion sobre la efectividad del coste, tienen que evaluarse los costes 
de los cambios requeridos para hacerque el componente sea reutilizable. Estos costes son los 
costes de la documentacion del componente, la validacion del componente y los costes para 
hacer que el componente sea mas generico. Los cambios que pueden hacerse para que un com- 
ponente sea mas reutilizable incluyen: 

• Eliminar los metodos especificos de la aplicacion. 

• Cambiar los nombres para hacerlos mas generales. 

• Anadir metodos para proporcionar una cobertura funcional mas completa. 

• Hacer que el manejo de excepciones sea consistente para todos los metodos. 

• Anadir una interfaz de «eonfiguracion» para permitir que el componente se adapte a di- 
ferentes situaciones de uso. 

• Integrar los componentes requeridos para incrementar la independencia. 

El problema del manejo de excepciones es particularmente dificil. En principio, todas las 
excepciones deberian formar parte de la interfaz del componente. Los componentes no debe- 
rian manejar las excepciones por si mismos. En su lugar, el componente deberia definir que 
excepciones pueden ocurriry deberia publicarlas como parte de su interfaz. Por ejemplo, un 
sencillo componente que implemente una estructura de pila de datos deberia detectar y hacer 
publicas las excepciones de desbordamiento y la falta de elementos. En la practica, sin em- 
bargo, un componente puede proporcionar algiin manejo de excepciones local, y cambiar esto 
puede tener implicaciones serias para la funcionalidad del componente. 

Mili y otros (Mili et ai, 2002) plantean formas de estimar los costes para hacer que un 
componente sea reutilizable y estimar el resultado de esta inversion. Los beneficios de reuti- 
lizar en lugar de redesarrollar un componente no son simples ganancias en cuanto a produc- 
tividad. Tambien pueden incluir ganancias en cuanto a calidad, debido a que el componente 
reutilizado suele ser mas confiable, y ganancias en cuanto a oportunidad de mercado. Tam- 
bien se pueden tener en cuenta las ganancias como consecuencia de desplegar el software mas 
rapidamente. Mili y otros presentan varias formulas para estimar estas ganancias, al igual que 
lo hace el modelo C O C O M O descrito en el Capitulo 26 (Boehm el ah, 2000). Sin embargo, 
los parametros de estas formulas son dificiles de estimar con exactitud, y las formulas deben 
adaptarse a circunstancias locales. Se presume que estos factores conllevan que muy pocos 
gestores de proyectos software esten dispuestos a confiar en ellas. 

Obviamente, si un componente es reutilizable o no, depende de su dominio de aplicacion 
y funcionalidad. A medida que se anade generalidad a un componente, se incrementa su reu- 
sabilidad. Sin embargo, esto normalmente implicaque el componente tenga mas operacio- 
nes y sea mas complejo, lo que hace que el componente sea mas dificil de comprendery uti- 
lizar. 

Existe un desequilibrio inevitable entre reusabilidad y la usabilidad de un componente. Ha- 
cer que el componente sea reutilizable implica proporcionar una serie de interfaces genericas 
con operaciones que abarcan todas las formas en las cuales el componente podria ser utiliza- 
do. Hacer que el componente sea usable significa proporcionar una interfaz minima sencilla 
que sea facil de comprender. La reusabilidad anade complejidad y, por eso, reduce la com- 
prensibilidad del componente. Por lo tanto, es mas dificil decidir cuando y como reutilizar ese 
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componente. Cuando se disefta un componente reutilizable, se debe buscar un equilibrio en- 
tre generalidady comprensibilidad. 

Otra importante fiiente de componentes son los sistemas heredados existentes. Tal y 
como se expuso en el Capitulo 2, hay sistemas que desempenan una funcion importante 
para la empresa, pero estan escritos utilizando tecnologias software obsoletas. Debido a 
esto, puede ser dificil utilizarlos con nuevos sistemas. Sin embargo, si se convierten estos 
sistemas antiguos en componentes, su funcionalidad puede reutilizarse en aplicaciones 
nuevas. 

Desde luego, estos sistemas heredados normalmente no tienen definidas claramente las 
interfaces requiere y proporciona. Para hacer que estos componentes sean reutilizables, tie- 
nen que definirse las interfaces del componente mediante lo que se conoce como wrapper. 
El wrapper oculta la complejidad del codigo subyacente y proporciona una interfaz para 
que los componentes externos puedan acceder a los servicios que dicho codigo proporcio- 
na. Naturalmente, este wrapper es un elemento de software bastante complejo ya que tie- 
ne que acceder a la funcionalidad del sistema heredado. Sin embargo, el coste del desa- 
rrollo de un wrapper es a menudo mucho menor que el coste de reimplementar el sistema 
heredado. 

19.2 El proceso CBSE 

Se ha sugerido en la introduccion que la reutilizacion con exito de componentes requiere un 
proceso de desarrollo adaptado aCB SE. La estructura de dicho proceso se analizo en el Ca- 
pitulo 4; la Figura 19.6 muestra las principales subactividades dentro de un proceso CBSE. 
Algunas de las actividades dentro de este proceso, tales como el descubrimiento inicial de los 
requerimientos del usuario, se llevan a cabo de la misma forma que en otros procesos soft- 
ware. Sin embargo, las diferencias fundamentales entre este proceso y los procesos software 
basados en el desarrollo original del software son las siguientes: 

1 . Los requerimientos del usuario se desarrollan inicialmente en forma de esquema en lu- 
gar de con detalle, y los stakeholders son alentados a ser lo mas flexibles posible en la 
definicion de sus requerimientos. La razon de esto es que los requerimientos muy es- 
pecificos limitan el numero de componentes que podrian satisfacer estos requeri- 
mientos. Sin embargo, y a diferencia del desarrollo incremental, se necesita un con- 
junto completo de requerimientos con el fin de que se puedan identificar para su 
reutilizacion tantos componentes como sea posible. 



Figura 19.6 
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2. Los requerimientos son refinados y modificados en etapas tempranas en ei proceso 
dependiendo de los componentes disponibles. Si los requerimientos del usuario no 
pueden ser satisfechos por los componentes disponibles, deberian discutirse los re- 
querimientos relacionados que pueden ser soportados. Los usuarios pueden estardis- 
puestos a cambiar sus ideas si esto significa entregar el sistema mas rapidamente y con 
un menorcoste economico. 

3. Hay una actividad adicional de busqueda de componentes y refinamiento de disefio des- 
pues de que la arquitectura del sistema haya sido disenada. Algunos componentes apa- 
rentemente usables pueden resultar no adecuados o pueden no trabajar adecuadamen- 
te con otros componentes seleccionados. Aunque no se muestra en la Figura 19.6, esto 
implica que pueden ser necesarios cambios adicionales en los requerimientos. 

4. El desarrollo es un proceso de composicion en el que se integan los componentes des- 
cubiertos. Esto implica la integracion de componentes con la infraestructura del mo- 
delo de componentes y, a menudo, desarrollar «codigo pegamento» para conciliar las 
interfaces de los componentes incompatibles. Por supuesto, puede requerirse funcio- 
nalidad adicional por encima y por debajo de la proporcionada por los componentes 
usables. Naturalmente, se deberia desarrollar esto como componentes que pueden ser 
reutilizados en sistemas futuros. 

La etapa de disefio arquitectonico es particularmente importante. Durante el disefio arqui- 
tectonico, se puede optar finalmente por un modelo de componentes, aunque, para muchos sis- 
temas, esta decision se hara antes de que comience la busqueda de componentes. Tal y como 
se ha explicado en los Capitulos del 11 al 13, tambien se establece la organizacion de alto ni- 
vel del sistema y se toman decisiones sobre la distribucion del sistema y el control. Jacobsen 
y otros (Jacobsen eral., 1997) afirman que definir una arquitectura robusta es critico para una 
reutilizacion exitosa. 

Una actividad que es unicapara el proceso CBSE es la identificacion de componentes. Esta 
implica varias subactividades, tal y como se muestra en la Figura 19.7. Hay dos etapas en el 
proceso CB SE en las que usted tiene que identificar componentes para su posible uso en el 
sistema. En etapas tempranas del desarrollo, la atencion deberia centrarse en la busqueda y 
seleccion. Es necesario convencerse a si mismo de que hay componentes disponibles que sa- 
tisfacen los requerimientos. Obviamente, deberia realizarse alguna comprobacion inicial de 
que el componente es adecuado, pero puede que no se necesiten pruebas detalladas. En eta- 
pas posteriores, despues de que se haya disenado la arquitectura del sistema, deberia invertir- 
se mas tiempo en la validacion de componentes. Hay que asegurarse de que los componentes 
identificados son realmente adecuados para su aplicacion; si no, tienen que repetirse los pro- 
cesos de busqueda y seleccion. 

Laprimera etapa en la identificacion de componentes es la busqueda de componentes que 
estan disponibles localmente o son de proveedores de confianza. La vision de los defensores 
de CBSE como Szyperski (Szyperski, 2002) es que deberia haber un mercado de componen- 
tes viable en donde los vendedores extemos compitan para proporcionar componentes. En el 
momenta de escribir este libro, esto no es una realidad. Laprincipal razon para ello es que los 
usuarios de componentes externos se enfrentan con los riesgos de que estos componentes no 
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funcionen lal y como se les dice. Si esle es el caso, los costes de reutilizacion superan a los 
beneficios, y pocos gestores de proyectos creen que los riesgos merecen la pena. Otra impor- 
tante razon de por que los mercados de componentes no se han desarrollado es que muchos 
componentes estan especializados en dominios de aplicaciones. No hay un mercado sufi- 
cientemente grande en estos dominios para que los suministradores de componentes extemos 
puedan establecerun negocio viable a largo plazo. 

Como consecuencia, la busqueda de componentes a menudo se ve restringida a la misma 
organizacion que desarrolla el software. Las compafiias de desarrollo de software pueden for- 
mar su propia base de datos de componentes reutilizables sin los riesgos inherentes al uso de 
componentes de suministradores externos. 

Una vez que el proceso de busqueda de componentes ha identificado componentes candi- 
dates, tienen que seleccionarse componentes especificos a partir de esta lista. En algunos ca- 
sos, esta sera una tarea sencilla. Los componentes de la lista se corresponderan directamente 
con los requerimientos del usuario, y no habra componentes que compitan para satisfacer es- 
tos requerimientos. Sin embargo, en otros casos, el proceso de seleccion es mucho mas com- 
plejo. No habra una clara correspondencia entre requerimientos y componentes, y se obser- 
vara que tienen que utilizarse varios componentes para satisfacer un requerimiento especifico 
o grupo de requerimientos. Desgraciadamente, es probable que diferentes requerimientos re- 
quieran diferentes grupos de componentes, por lo que habra que decidir que composicion de 
componentes proporcionan el mejor cumplimiento de los requerimientos. 

Una ve?, que se han seleccionado los componentes para su posible inclusion en un siste- 
ma, habria que validarlos para comprobar que se comportan como deberian. El alcance de va- 
lidacion requerido depende de la fuente de los componentes. Si se esta usando un componente 
que ha sido desarrollado por una fuente conocida de confianza, puede decidirse que pruebas 
de componentes independientes no son necesarias, y se prueba el componente cuando se in- 
tegra con otros componentes. Por otro lado, si se esta utilizando un componente proveniente 
de una fuente desconocida, siempre se deberia comprobar y verificar ese componente antes 
de incluirlo en el sistema. 

La validacion de componentes implica desarrollar un conjunto de casos de prueba para el 
componente (o. posiblemente, extender los casos de prueba proporcionados con el compo- 
nente) y desarrollar software adicional de pruebas para ejecutar las pruebas de componentes. 
El principal problema con la validacion de componentes es que la especificacion del compo- 
nente puede no ser lo suficientemente detallada para permitir desarrollar un conjunto completo 
de pruebas de componentes. Los componentes se especifican normalmente de manera infor- 
mal, siendo launicadocumentacion formal la especificacion de su interfaz. Esta puede no in- 
cluir suficiente informacion para desarrollar un conjunto completo de pruebas que podrian lle- 
var a la conviccion de que la interfaz de dicho componente es la que se requiere. 

Un problema adicional de validacion, que podria ocurrir en esta etapa, es que el compo- 
nente puede tener caracteristicas que interfieran en el uso que se hace del componente. Los 
componentes reutilizables a menudo tendran mas funcionalidad de la que se necesita. Se pue- 
de simplemente prescindir de la funcionalidad que no se necesita, pero esta puede a veces in- 
terferir en oiros componentes o en el sistema en su totalidad. En algunos casos, la funciona- 
lidad no deseada puede incluso causar fallos graves del sistema. La Figura 19.8 describe 
brevemente una situacion en la que la funcionalidad no necesaria en un sistema reutilizado 
provoco un fallo catastrofico del software. 

El problema en la lanzadera del Ariane 5 ocurrio debido a que las suposiciones hechas para 
el Ariane 4 no eran validas para el Ariane 5. Este es un problema general que presentan los 
componentes reutilizables. Estos son implementados originalmenie para un enlomo de apli- 
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E ffaMo ea la lmaMOmde\ Aitarte S 

Mienbas se desanoMaba la bnzadeia espadal del Ariane 5, los disenadores 
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Ariane 5. DebUo a que no habia requettmientDS para b funclon que fallo, no se 
desanolaran pruebas. ConsecuentementB, el proMema con el software nunca fue 
descubterto durante bs pruebas de simulacion de b bnzadeia. 



caciony, naturalmente, incluyen suposiciones sobre dicho entomo. Estas suposiciones son ra- 
ramente documentadas y, por lo tanto, cuando el componente es reutilizado, es imposible de- 
rivar pruebas para comprobar si las suposiciones son todavia validas. 

193 Composicion de componentes 

La composicion de componentes es el proceso de ensamblar componentes para crear un sis- 
tema. Si nosotros asumimos una situacion en la que los componentes reutilizables estan dis- 
ponibles, entonces la mayoria de los sistemas se construiran componiendo estos componen- 
tes reutilizables unos con otros, con componentes escritos de forma especial y con la 
infraestructura de soporte de los componentes proporcionada por el marco de trabajo del mo- 
delo. Tal y como se ha indicado en la Seccion 19.1, esta infraestructura proporciona facilida- 
des para soportar la comunicacion de componentes y los servicios horizontales como los ser- 
vicios de interfaz de usuario, gestionde transacciones, concurrencia y proteccion. Las formas 
en las que los componentes se integran con esta infraestructura son documentadas para cada 
modelo de componentes y no se tratan en esta seccion. 

La composicion no es unaoperacion sencilla; existen varios tipos de composiciones (Fi- 
gure 19.9): 

1 . Composicion secuencia!. Tiene lugar cuando, en el componente compuesto, los com- 
ponentes constituyentes se ejecutan en secuencia. Se corresponde con la situacion (a) 
en la Figura 19.9, en donde se componen las interfaces proporciona de cada compo- 
nente. Se requiere algun codigo extra para conseguir enlazar los componentes. 
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Figura 19.9 Tipos 
de composicion de 
componentes. 
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2. Composicion jerdrquica. Tiene lugar cuando un componente realiza una llamada di- 
rectamente a los servicios proporcionados por otro componente. Se corresponde con 
una situacion en que la interfaz proporciona de un componente se compone con la in- 
terfaz requiere de otro componente. Esta es la situacion (b) en la Figura 19.9. 

3. Composicion aditiva. Tiene lugar cuando las interfaces de dos o mas componentes se 
unen (se afiaden) para crear un nuevo componente. Las interfaces del componente 
compuesto se crean uniendo todas las interfaces de los componentes constituyentes, 
eliminando las operaciones duplicadas si es necesario. Esto se corresponde con la si- 
tuacion (c) de la Figura 19.9. 

Podrian utilizarse todas las formas de composicion de componentes al crear un sistema. En 
todos los casos, se puede tener que escribir «codigo pegamento» que enlaza los componen- 
tes. Por ejemplo, para la composicion secuencial, la salida de un componente A normalmen- 
te se convierte en la entrada para el componente B. Se necesitan sentencias intermedias que 
llamen al componente A. recojan el resultado y a continuacion llamen al componente B con 
dicho resultado como un parametro. 

Cuando se escriben componentes especialmente para composicion, se diseflan las interfa- 
ces de dichos componentes para que sean compatibles. Por lo tanto, se pueden componer fa- 
cilmente estos componentes en una unica unidad. Sin embargo, cuando los componentes se 
desarrollan de forma independiente para reutilizacion, se observaran a menudo incompatibi- 
lidades de interfaces en las que las interfaces de los componentes que se desea componer no 
son las mismas. Pueden darse tres tipos de incompatibilidades: 

1 . Incompatibilidad de pardmetros. Las operaciones a cada lado de la interfaz tienen el 
mismo nombre, pero los tipos de los parametros o su numero son diferentes. 

1. Incompatibilidad de operaciones. Los nombres de las operaciones en las interfaces 
proporciona y requiere son distintos. 

3 . Operaciones incompletas. La interfaz proporciona de un componente es un subcon- 
junto de la interfaz requiere de otro componente o viceversa. 

En todos los casos, el problema de la incompatibilidad se trata escribiendo un compo- 
nente adaptador que reconcilia las interfaces de los dos componentes que se estan reutili- 
zando. Cuando se conocen las interfaces de los componentes que se desea utilizar, se des- 
cribe un componente adaptador que convierte una interfaz en otra. La forma precisa del 
adaptador depende del tipo de composicion. Algunas veces, como en el siguiente ejemplo, 
el adaptador simplemente toma un resultado de un componente y lo convierte en una for- 
ma tal que pueda ser usada como entrada por otro. En otros casos, el adaptador puede ser 



416 



CAPITULO 19 • Ingenieria del software basada en componentes 



llamado por el componente A y el mismo llama al componente B. La ultima situacion po- 
dria ocurrir si A y B fiiesen compatibles pero el numero de parametros en sus interfaces fue- 
ra diferente. 

Para ilustrar los adaptadores, consideremos los componentes mostrados en la Figura 19.10. 
Estos podrian ser parte de un sistema utilizado por los servicios de emergencia. Cuando el 
operador de la emergencia recibe una llamada, el numero de telefono es la entrada para el 
componente addressFinder para localizar la direccion. A continuacion, utilizando el compo- 
nente mapper, se imprime un mapa para ser enviado al vehiculo asignado a la emergencia. 
De hecho, el componente podria tener interfaces mas complejas que las mostradas aqui, pero 
la version simplificada ilustra el concepto de un adaptador. 

El primer componente, addressFinder, encuentra la direccion que se correspondeconun 
numero de telefono. Tambien puede devolver el dueno de la propiedad asociada con el numero 
de telefono y el tipo de propiedad. El componente mapper tomaun codigo postal (en los Es- 
tados Unidos, un codigo estandar ZIP con los cuatro digitos adicionales que identifican la lo- 
calizacion de la propiedad) y visualiza o imprime un mapa de calles del area alrededor de di- 
cho codigo a una escala especificada. 

Estos componentes son componibles en principio debido a que la propiedad de localiza- 
cion incluye el codigo postal o ZIP. Sin embargo, tiene que escribirse un componente adap- 
tador llamado postCodeSt ripper que toma los datos de la localizacion de addressFinder y ex- 
trae el codigo postal. A continuacion, este codigo postal se utiliza como entrada para mapper, 
y el mapa de calles se visualiza a una escala de 1:10.000. El siguiente codigo ilustra la se- 
cuencia de llamadas requeridas para implementar esto: 

address = addressFinder. location(phonenumber); 
postcode = postCodeStripper.getPostCode(address); 
ma p per. displayM a p( postcode, 10000); 

Otro caso en el que puede utilizarse un componente adaptador es cuando un componente 
desea hacer uso de otro, pero hay una incompatibilidad entre las interfaces proporciona y re- 
quiere de estos componentes. Esto se ilustra en la Figura 19.1 1, en donde el componente re- 
colector de datos se conecta a un componente sensor utilizando un adaptador. Este concilia 
las interfaces del componente recolector de datos con las interfaces proporciona del compo- 
nente sensor. El componente recolector de datos fue disenado con un mecanismo requiere ge- 
nerico que no se baso en una interfaz de sensor especifica. Ya se adelanto que un adaptador 
siempre podria ser utilizado para conectar el recolector de datos con una interfaz especifica 
del sensor. 
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La discusion sobre la composicion de componentes supone que puede saberse a partir de 
la documentacion de los componentes si las interfaces son compatibles. Por supuesto, la de- 
finicion de la interfaz incluye el nombre de las operaciones y los tipos de los parametros, de 
forma que puede evaluarse la compatibilidad a partir de estas. Sin embargo, para decidir si las 
interfaces son semanticamente compatibles hay que partir de la documentacion de los com- 
ponentes. 

Por ejemplo, consideremos la composicion mostrada en la Figura 19.12. Estos compo- 
nentes se utilizan para implementar un sistema que descarga imagenes de una camara digital 
y las almacena en una libreria fotografica. El usuario del sistema puede proporcionar infor- 
macion adicional para describiry catalogar las fotografias. Para evitarconfusiones, no se han 
mostrado aqui todos los metodos de las interfaces, sino que simplemente se muestran los me- 
todos que son necesarios para ilustrar el problema de la documentacion de los componentes. 
Los metodos en la interfaz del componente que se ha denominado Photo Library son: 

public void addltem (Identifier pid; Photograph p; CatalogEntry photodesc); 
public Photograph retrieve (Identifier pid); 
public CatalogEntry catEntry (Identifier pid); 

Se asume que la documentacion parael metodo addltem del componente Photo Library es: 

Este metodo afiade una fotografia a la libreria y asocia el identificador de la fotografia 
y el identificador del catalogo con la fotografia. 

Esta descripcion parece que es comprensible, pero considere las siguientes cuestiones: 

iQue ocurre si el identificador de la fotografia ya esta asociado con una fotografia en 
la libreria? 

^Esta tambien asociado el descriptor de la fotografia con la entrada del catalogo ade- 
mas de la fotografia? Es decir, si yo borro la fotografia, ^tambien borro la informacion 
del catalogo? 
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No hay suficiente informacion en la descripcion informal de a d d 1 1 e m para responder a es- 
tas cuestiones. Por supuesto, es posible anadir mas informacion a la descripcion en lenguaje 
natural del metodo, pero, en general, la mejor forma de resolverambigiiedades es utilizarun 
lenguaje formal para describir la interfaz. En el Capitulo 10, se sugirio que la descripcion de 
la interfaz es un area en donde las especificaciones formales son bastante utiles. La especifi- 
cacion mostrada en la Figura 19.13 es parte de la descripcion de la interfaz del componente 
Photo Library que afiade informacion a la descripcion informal. 

La especificacion en la Figura 19.13 utilizapre y postcondiciones, y se ha empleado una 
notacion basada en el lenguaje de restricciones de objetos (OCL) que forma parte de U M L 
(Warmer y Kleppe, 1998). OCL se diseno para describir restricciones en los modelos de ob- 
jetos U M L ; permite expresar predicados que deben ser ciertos siempre, que deben ser ciertos 
antes de que un metodo sea ejecutado, y que deben ser ciertos despues de que un metodo sea 
ejecutado. Estos son los invariantes, precondiciones y postcondiciones respectivamente. Para 
acceder al valor de una variable antes de una operacion, se afiade @pre despues de su nom- 
bre. Por lo tanto: 

age = ageOpre +1 

significa que el valor de la variable age despues de una operacion es uno mas del valor que 
tenia antes de dicha operacion. 

Las aproximaciones basadas en OCL se estan utilizando cada vez mas para anadir infor- 
macion semantica a los modelos U M L . La aproximacion general se ha derivado de la apro- 
ximacion al Diseno mediante Contratos de Meyer (Meyer, 1992), en la cual las interfaces y 
obligaciones de comunicacion de los objetos son especificadas formalmente y forzadas por el 
sistema de ejecucion. Meyer sugiere que el uso de disefios por contratos es esencial si esta- 
mos desarrollando componentes fiables (Meyer, 2003). 
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La Figura 1 9. 13 incluye una especificacion para los metodos addltem y delete en el com- 
ponente Photo library. El metodo que se esta especificando se indica con la palabra clave 
context, y las pre y postcondiciones con las palabras clave pre y post. Las precondiciones 
para addltem sefialan que: 

• No deberia haber una fotografia en la libreria con el mismo identificador que la nueva 
fotografia a aftadir. 

• La libreria debe existir — se supone que la creacion de una libreria anade un unico ele- 
mento a esta de forma que el tamaflo de una libreria siempre es mayor que cero. 

Las postcondiciones para add'tem senalan que: 

• El tamaflo de la libreria ha crecido en uno (de forma que solamente se ha efectuado una 
entrada). 

• Si usted recupera utilizando el mismo identificador, entonces vuelve a la fotografia que 
usted afiadio. 

• Si usted busca en el catalogo utilizando ese identificador, vuelve a la entrada del catalo- 
go que hizo. 

La especificacion de delete proporciona informacion adicional. La precondicion indica 
que, para borrar un elemento, este debe estar en la libreria y, despues de su borrado, la fo- 
tografia ya no puede ser recuperada y el tamaflo de la libreria se reduce en uno. Sin em- 
bargo, delete no borra la entrada del catalogo — todavia es posible recuperarla despues de 
que la foto haya sido borrada — . La razon de esto es que puede quererse mantener infor- 
macion en el catalogo de por que una foto fue borrada, su nueva localizacion, y asi sucesi- 
vamente. 

Cuando se crea un sistema mediante la composicion de componentes, se puede observar 
que hay conflictos potenciales entre los requerimientos funcionales y no funcionales, la ne- 
cesidad de entregar un sistema tan rapidamente como sea posible, y la necesidad de crear un 
sistema que pueda evolucionar a medida que los requerimientos cambian. Las decisiones en 
las que se tiene que llegar a un equilibrio son: 

1 . iQue composicion de componentes es mas efectiva para satisfacer los requerimientos 
funcionales del sistema? 

2. ^Que composicion de componentes permite adaptaciones para futuros cambios sobre 
los requerimientos? 

3. ^Cuales seran las propiedades emergentes del sistema compuesto? Estas propiedades 
emergentes son propiedades tales como rendimiento y confiabilidad. Solamente pue- 
den evaluarse una vez que el sistema completo esta implementado. 

Desgraciadamente, hay muchas situaciones en las que las soluciones a los problemas de la 
composicion estan en conflicto mutuo. Por ejemplo, consideremos una situacion tal como la 
que se ilustra en la Figura 19.14, en donde un sistema puede ser creado a traves de dos alter- 
nativas de composiciones. El sistema es un sistema de informes y recoleccion de datos en el 
que los datos se recogen desde diferentes fuentes, se almacenan en una base de datos, y se ela- 
bora un informe que resume estos datos. 

Las ventajas de la composicion (a) son que la gestion e informes de datos son indepen- 
dientes, con lo que hay mas flexibilidad para futuros cambios, El sistema de gestion de datos 
podria ser reemplazado y, si se requieren informes que el componente de informes actual no 
puede producir, ese componente tambien puede ser reemplazado. En la composicion (b), se 
usa un componente de base de datos con facilidades de informes embebidos en ella (por ejem- 
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pio Microsoft Access). Las ventajas de la composicion (b) son que hay menos componentes, 
con lo que el sistema probablemente sera mas rapido debido a que no hay sobrecargas de co- 
municacion entre los componentes. Ademas, las reglas de integridad de datos que se aplican 
a la base de datos tambien se aplicaran a los informes. Estos informes no podran combinar 
datos de forma incorrecta. En la composicion (a), no hay tales restricciones, por lo que los 
errores en los informes son mas probables. 

En general, un buen principio de composicion a seguir es el principio de la separacion de 
papeles. Es decir, deberia intentarse disenar el sistema de forma que cada componente tenga 
un papel claramente definido e, idealmente, estos papeles no deberian solaparse. Sin embar- 
go, puede ser mas economico construir un componente multifuncional en lugar de dos o tres 
componentes independientes. Ademas, el sistema puede sufrir penal i zac iones en cuanto a con- 
fiabilidad o rendimiento cuando se utilizan multiples componentes. 



PUNTOS CLAVE 

• La ingeniena del software basada en componentes es una aproximacion basada en la reutilizacion para defi- 
nir, implementarycomponercomponentes independientes debilmente acoplados para formar sistemas. 

• Un componente es una unidad software cuya funcionalidad y dependencias estan completamente definidas 
por un conjunto de interfaces publicas. Los componentes pueden combinarse con otros componentes sin ha- 
cer referenda a su implementaciony pueden ser desplegados como una unidad ejecutable. 

• Un modelo de componentes define un conjunto de estandares para componentes, incluyendo estandares de 
interfaz, est and a resde usoyestandaresde despliegue. Lalmplementaciondel modelo de componentes pro- 
porciona un conjunto de servicios horizontales que pueden ser utilizados portodos los componentes. 

• Durante el proceso CBSE, tienen que intercalarse los procesos de Ingeniena de requerimientos y diseno del 
sistema. Se tiene que alcanzar un equilibrio entre requerimientos deseables frente a servicios que estan dis- 
ponibles por componentes reutilizables existentes. 

• La composicion de componentes es el proceso de enlazar componentes para crear un sistema. Los tipos de 
composicion incluyen composicion secuencial, composicion Jerarqulca y composicion aditiva. 

• Cuando se componen componentes reutilizables que no han sido creados explicitamente para laaplicacion 
en ta que se desea reutilizartos, normalmente se necesitara escribir adaptadores o «codigo pegamento» para 
conciliar las diferentes interfaces de los componentes. 
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• En la eleccion de composiciones, tiene que considerarse la funcionalidad requerida del sistema, los requeri- 
mientos no funcionales y la facilidad con la que un componente puede ser reemplazado por otro cuando el sis- 
tema cambia. 



LECTURAS AD ICI ON ALES • • • ife» W AA MWKKBUW A -&MWKKUB, A M 

Component-based Software Engineering: Putting the Pieces Together. Este libro es una coleccion de articulos de va- 
rios autores sobre diferentes aspectos de CB5E. Como todas las colecciones, es muy variado, pero estudia bastan- 
te mejor los aspectos generates de la ingenieria del software con componentes que el libro de Szyperski. (G. T. Hei- 
neman y W. T. Councill, 2001, Addison- Wesley.) 

Component Software: Beyond Object-Oriented Programming, 2nd ed. Esta edicion actualizada del primer libro so- 
bre CBSE trata cuestiones tecnicas y no tecnicas en CBSE. Incluye mas detalles sobre tecnologias especificas que el 
libro de Heinemany Councill ypresentaun estudio sobre cuestiones de mercado. (C. Szyperski, 2002, Addison- Wes- 
ley.) 

"Specification, Implementation and deployment of components)). Una buena introduccion a los fundamentos de 
CBSE. El mismo numero de CACM incluye articulos sobre componentes y desarrollo basado en componentes 
[I. Crnkovic, ef ai, Comm. ACM, 45(10), octubre, 2002.] 



19.1 iPor que es importante que todas las interacciones entre componentes se definan a traves de interfaces 
requiere y proporciona? 

19.2 El principio de independencia de componentes implica que sea posible reemplazar un componente por 
otro que este implementado de una forma completamente diferente. Usando un ejemplo, comente como 
tal reemplazo de componentes podria tener consecuencias no deseadas y podria conducir a un fallo de fun- 
cionamiento del sistema. 

19.3 ^Cuales son las diferencias fundamentales entre componentes y servicios web? (vease elCapitulo 12.) 

19.4 {jPor que es importante que los componentes se basen en un modelo de componentes estandar? 

19.5 Utilizando un ejemplo de un componente que implemente un tipo abstracto de datos tal como una pila o 
una lista, demuestre por que normalmente es necesario extender y adaptar los componentes para su reu- 
tilizacion. 

19.6 Explique por que es muy dificil validar un componente reutilizable sin el codigo fuente del componente. 
^De que formas podria una especificacion formal de componentes simplificar el problema de validacion? 

19.7 Disene un componente reutilizable que implemente la caracteristica de busqueda del sistema LIBSYS des- 
crito en capitulos anteriores. Este no implementa una simple busqueda por palabra clave de paginas web. 
Tiene que ser capaz de buscar los catalogos de varias bibliotecas, tal y como especifica el usuario. 
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19.8 Utilizando ejemplos, ilustre los diferentes tipos de adaptadores necesarios para soportar composicion se- 
cuencial, composicion jerarquica y composicion aditiva. 

19.9 Disene las interfaces de los componentes que podrian utilizarse en un sistema de una sala de control de 
emergencias. listed deberfa disenar interfaces para un componente de registro de llamadas que registre 
las llamadas realizadas, y un componente de busquedadevehiculos que, dado un cod i go postal y un tipo 
de incidente, encuentre el vehiculo adecuado mas cercano para ser enviado al lugar del incidente. 



19.10 



Se ha sugerido que podria establecerse una autoridad de certif icacion independiente. Los vendedores po- 
drian someter sus componentes a esta autoridad, quien podria validar que el componente fuera fiable. 
iCuales podrian ser tas ventajas y desventajas de dicha autoridad de certif icacion? 



20 

Desarrollo 

de sistemas cnticos 



Objetivos 

El objetivo de este capitulo es introducir las tecnicas de 
implementacion utilizadas en el desarrollo de sistemas cnticos. 
Cuando haya leido este capitulo: 

• comprendera como el evitar los defectos y la tolerancia a 
defectos contribuye al desarrollo de sistemas confiables; 

• conocera las caracteristicas y las actividades de los procesos 
software confiables; 

• habra sido introducido en las tecnicas de programacion para 
evitar defectos; 

• comprendera las etapas implicadas en ta implementacion de la 
tolerancia a defectos y las formas en las que ta diversidad y (a 
redundancia son utilizadas en arquitecturas tolerantes a 
defectos. 

Contenidos 

20.1 Procesos confiables 

20.2 Programacion confiable 

20.3 Tolerancia a defectos 

20.4 Arquitecturas tolerantes a defectos 



424 CAPITU LO 20 • Desarrollo de sistemas cnticos 



Tecnicas de ingenieriadel software mejoradas, mejores lenguajes deprogramacionyuname- 
jor gestionde lacalidadhan contribuido a mejoras significativas en laconfiabilidadde lama- 
yoria del software. Sin embargo, los sistemas cnticos, tales como aquellos que controlan ma- 
quinaria automatica, sistemas medicos, centrales de telecomunicaciones o aviones necesitan 
niveles mas altos de confiabilidad. En estos casos, pueden utilizarse tecnicas de desarrollo es- 
peciales para asegurar que el sistema es seguro, protegido y fiable. 

Existen dos aproximaciones complementarias para desarrollar software confiable: 

1. Prevention de defectos. El proceso de disefio e implementacion del sistema deberia 
utilizar aproximaciones al desarrollo del software que ayuden a evitar errores de pro- 
gramaciony asi minimizar el numero de defectos en unprograma. 

2. Detection de defectos. Los procesos de verificacion y validacion se disefian para 
descubrir y validar defectos en un programa antes de que este sea desplegado para 
su uso. 

3. Tolerancia a defectos. El sistema se disefia para que los defectos o comportamientos 
inesperados del sistema durante la ejecucion sean detectados y gestionados de tal for- 
ma que no ocurran fallos de funcionamiento. 

Este capitulo se centra en las tecnicas y procesos que soportan la prevencion de defectos y 
la tolerancia a defectos. La deteccion de defectos es un tema importante por derecho propio 
y se trata en la Parte 5 de este libro. Se estudian tecnicas estaticas para la deteccion de defec- 
tos en el Capitulo 22, las pruebas de programas en el Capitulo 23 y las tecnicas de verifica- 
cion y validacion especificas para sistemas cnticos en el Capitulo 24. 

Resulta fundamental, para conseguir la confiabilidad en cualquier sistema, nociones basi- 
cas sobre redundancia y diversidad. La redundancia y la diversidad son estrategias cotidianas 
para evitar los fallos de ejecucion. Si una persona invierte en bolsa de valores, no coloca to- 
das sus inversiones en unaunicacompania, yaque podriaperder todo si lacompafiiaquiebra 
(diversidad). Las personas guardan baterias de reserva y bombillas en sus casas para poder re- 
cuperarse rapidamente de fallos electricos (redundancia). Nosotros deberiamos hacercopias 
de seguridad de nuestras computadoras de forma regular en caso de un fallo en el disco (re- 
dundancia) y, para asegurar nuestros hogares, a menudo tenemos mas de un tipo de cerradu- 
ra en la puerta (diversidad). 

Los sistemas criticos pueden incluir componentes que reproducen la funcionalidad de 
otros componentes (redundancia) o codigo de comprobacion adicional que no es estrictamente 
necesario para que el sistema funcione (redundancia). Por lo tanto, los defectos pueden de- 
tectarse antes de que ocasionen fallos de funcionamiento, y el sistema puede ser capaz de con- 
tinuar funcionando si los componentes individuales fallan. Si los componentes redundantes 
del sistema no son exactamente iguales que otros componentes (diversidad), un fallo de fun- 
cionamiento en el componente duplicado tendra como resultado un fallo de funcionamiento 
en el sistema completo. 

En los sistemas en los que la disponibilidad es un requerimiento critico, normalmente es- 
tan disponibles servidores redundantes. Estos automaticamente se ponen en funcionamiento 
si un determinado servidor falla. Algunas veces, para asegurar que los ataques sobre el siste- 
ma no puedan explotar alguna vulnerabilidad comun, estos servidores pueden ser de diferen- 
tes tipos y ejecutarse sobre diferentes sistemas operativos. El uso de diferentes sistemas ope- 
ratives es un ejemplo de diversidad y redundancia del software. En otros casos, tal y como se 
explica mas adelante, la diversidad y la redundancia pueden ser embebidas en el software in- 
cluyendo componentes software redundantes que han sido programados de forma deliberada 
utilizando distintas tecnicas. 
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La diversidad y la redundancia tambien se utilizan para conseguir procesos confiables. Al 
igual que cuando se prueba un programa, pueden utilizarse inspecciones de programas y ana- 
lisis estatico como tecnicas para encontrar defectos. Estas tecnicas de validacion son com- 
plementarias: unapuede encontrar defectos que son ocultados porotra. Ademas, lamisma ac- 
tividad del proceso (por ejemplo, una inspeccion de programa) puede ser llevada a cabo por 
varios miembros del grupo: las personas asumen tareas de diferentes formas dependiendo de 
su personalidad, experiencia y educacion, de modo que este tipo de redundancia proporciona 
una perspectiva variada del sistema. 

Por desgracia, anadir diversidad y redundancia a los sistemas los hace mas complejos y. 
por lo tanto, mas dificiles de entender. Por esta razon, es mas probable que los programa- 
dores comentan errores y menos probable que las personas que prueben el programa en- 
cuentren errores. Como consecuencia, algunas personas piensan que es mejor evitar la re- 
dundancia y la diversidad en el software, y asi disefiar el sistema para que sea lo mas 
sencillo posible y permitir realizar procedimientos de verificacion y validacion con una ri- 
gurosidad extrema (Pamas et al., 1990). Ambas aproximaciones se utilizan en sistemas de 
seguridad criticos comerciales. El sistema de control de vuelo del Airbus 340 es diverso y 
redundante (Storey, 1996), mientras que el sistema de control de vuelo del Boeing 777 se 
basa en una version sencilla del software. 

Un objetivo en la investigacion en ingenieria del software ha sido el desarrollar herra- 
mientas, tecnicas y metodos que lleven a la produccion de software libre de defectos. El soft- 
ware libre de defectos es el software que cumple exactamente con su especificacion. Sin em- 
bargo, esto no significa que el software nunca falle. Puede haber errores en la especificacion 
que se reflejan en el software, o los usuarios pueden no comprender o no usar bien el sistema 
software. Sin embargo, eliminar los defectos del software ciertamente tiene un enorme im- 
pacto sobre el numero de fallos de ejecucion del sistema. 

Para sistemas de tamafio pequefio y medio, nuestras tecnicas de ingenieria del software son 
tales que probablemente sea posible desarrollar software libre de defectos. Para alcanzar este 
objetivo, es necesario utilizar varias tecnicas de ingenieria del software: 

1 . Procesos software confiables. El uso de un proceso software confiable (analizado en 
la Seccion 20.1) con actividades de verificacion y validacion adecuadas resulta esen- 
cial si tiene que minimizarse el numero de defectos en el programa, y tienen que de- 
tectarse aquellos que se produzcan. 

2. Gestion de calidad. La organizacion que desarrolla el sistema debe tener una cultura 
en la que la calidad guie el proceso software. Esta cultura deberia motivar a los pro- 
gramadores a escribir programas libres de errores. Deberian establecerse estandares de 
diseno y desarrollo, asi como procedimientos para comprobar que dichos estandares 
se cumplen. 

3. Especificacion formal. Debe realizarse una especificacion del sistema precisa (prefe- 
riblemente formal) que defina el sistema que se va a implementar. Muchos errores de 
diseno y programacion son el resultado de una mala interpretacion de una especifica- 
cion ambigua o pobremente redactada. 

4. Verificacion estdtica. Las tecnicas de verificacion estaticas, como el uso de analiza- 
dores estaticos, pueden encontrar caracteristicas anomalas en el programa que podri- 
an ser defectos. Tambien podria usarse verificacion formal, basada en la especificacion 
del sistema. 

5. Jipadofuerte. Para el desarrollo se debe usar un lenguaje de programacion fuerte- 
mente tipado, como Java o Ada. Si el lenguaje es fuertemente tipado, el compilador 
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del lenguaje puede detectar muchos errores de programacion antes de que puedan ser 
introducidos en el programa entregado. 

6. Programacion segura. Algunas construcciones de lenguajes de programacion son mas 
complejas y propensas a error que otras, y es mas probable que se cometan errores si 
se usan. La programacion segura significa evitar, o al menos minimizar, el uso de es- 
tas construcciones. 

7. Information protegida. Deberia utilizarse una aproximacion para el disefio e imple- 
mentacion del software basada en la ocultacion y encapsulamiento de la informacion. 
Los lenguajes orientados a objetos como Java, obviamente satisfacen esta condicion. 
Se deberia fomentar el desarrollo de programas disenados para ser legibles y com- 
prensibles. 

Se han comentado algunas de estas tecnicas en otros capitulos del libro. Este capitulo se 
centra en la descripcion de procesos software confiables y tecnicas de programacion que con- 
tribuyen a laprevencion de defectos. 

Sin embargo, hay situaciones dificiles en las que es economicamente practico utilizar 
todas estas tecnicas para crear software libre de defectos. El coste de encontrar y elimi- 
nar defectos en el sistema crece exponencialmente a medida que se descubren y eliminan 
los defectos en el programa (Figura 20.1). A medida que el software se hace mas fiable, 
se necesita emplear mas y mas tiempo y esfuerzo para encontrar menos y menos defec- 
tos. En algun momento, los costes de este esfuerzo adicional se convierten en injustifi- 
cables. 

Como consecuencia, las companias de desarrollo de software aceptan que su software 
siempre tendra algun defecto residual. El nivel de defectos depende del tipo de sistema. Los 
productos relacionados con sistemas no cnticos tienen un relativamente alto nivel de defec- 
tos (aunque son mucho mejores que hace diez anos), mientras que los sistemas cnticos nor- 
malmente tienen mucha menor densidad de defectos. 

El razonamiento para aceptar defectos es que, si y cuando el sistema falla, es mas barato 
pagar por las consecuencias de un fallo de funcionamiento que descubrir y eliminar los de- 
fectos antes de la entrega del sistema. Sin embargo, tal y como se explica en el Capitulo 3, 
la decision de entregar software con defectos no es simplemente economica. La aceptabili- 
dad social y politica de un fallo de funcionamiento del sistema tambien ha de tenerse en 
cuenta. 
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20.1 Procesos confiables 

Los procesos software confiables son procesos que estan adaptados a la prevencion y detec- 
cion de defectos. Los procesos confiables estan bien definidosy son repetibles, e incluyenuna 
variedad de actividades de verificacion y validacion. Un proceso bien definido es un proceso 
que ha sido estandarizado y documentado. Un proceso repetible es aquel que no depende de 
unjuicio e interpretacion individual. Independientemente de la gente implicada en el proce- 
so, la organizacion puede estar segura de que el proceso se realizara con exito. Se estudia la 
importancia de los procesos para conseguir calidad del software y la mejora de los procesos 
en el Capitulo 28. Las caracteristicas fundamentales de los procesos confiables se muestran 
en la Figura 20.2. 

Un proceso confiable deberia incluir siempre actividades de verificacion y validacion bien 
planificadas y organizadas cuyo objetivo es asegurar el descubrimiento de defectos residua- 
les en el software antes de que este sea desplegado. Las actividades del proceso que se llevan 
a cabo para prevenir y detectar los defectos comprenden: 

1. Inspecciones de requerimientos. Tal y como se explico en el Capitulo 7, estas preten- 
den descubrirproblemas en laespecificaciondel sistema. Unaproporcionelevadade 
defectos en el software entregado es consecuencia de errores en los requerimientos. Si 
estos pueden descubrirse y eliminarse de la especificacion, entonces esta clase de de- 
fectos se minimizaran. 

2. Gestion de requerimientos. La gestion de requerimientos, tratada en el Capitulo 7, 
esta relacionada con la realizacion de un seguimiento de los cambios en los reque- 
rimientos y extender dicho seguimiento a lo largo del diseno y la implementacion. 
Muchos errores en los sistemas entregados son el resultado de no asegurar que real- 
mente se incluya un cambio de requerimientos en el diseno e implementacion del 
sistema. 

3. Verificacion de modelos. La verificacion de modelos implica el uso de herramientas 
CASE para analizar los modelos del sistema y asegurar su consistencia interna y ex- 
terna. La consistencia interna significa que un modelo del sistema es consistente; la 
consistencia externa significa que diferentes modelos del sistema (por ejemplo, un 
modelo de estados y un modelo de objetos) son consistentes. 





Documentable 


El proceso deberfa tener un modelo de procesos definido que deter- 
mine las actividades del proceso y la documentacidn que tiene que 
produdrse durante estas actividades. 


Estandarizado 


Deberia estar disponible un conjunto complete de estandares de des- 
arroHo del software que definan como el software tiene que ser pro- 
ducido y documentado. 


AudttaMe 


El proceso deberia ser comprensible para las personas ajenas a los 
parbcipantes en ei proceso, quienes pueden prober que los estanda- 
res del proceso se estan siguiendo y realizar sugerencias para la me- 
jora del proceso. 


Dtverso 


El proceso deberia induir diversas actividades de verificacion y va6daci6n. 


Robusto 


El proceso deberfa ser capaz de recuperarse de fados de ejecuci6n de 
actividades del proceso individual. 
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4. Inspecciones de diseno y codigo. Tal y como indica en el Capitulo 22, las inspeccio- 
nes de diseno y codigo a menudo se basan en listas de verificacion de defectos comu- 
nes y pretenden descubrir y eliminar estos defectos antes de la prueba del sistema. 

5. Andlisis estdtico. El analisis estatico es una tecnica automatica de analisis de progra- 
mas en la que el programa se analiza con detalle para encontrar condiciones poten- 
cialmente erroneas. Esto se trataen el Capitulo 22. 

6. Planiflcacion y gestidn de ;as pruebas. Deberia disenarse un conjunto completo de 
praebas para el sistema y gestionar cuidadosamente el proceso de pruebas para ase- 
gurar una cobertura completa de las pruebas y el seguimiento de tos requerimientos 
y el diseno del sistema a traves de tas pruebas. Las pruebas se estudian en el Capi- 
tulo 23. 

Una posible fuente de error en sistemas criticos consiste en incluir el componente erroneo 
o la version erronea de un componente en el sistema. Para evitar esto, se necesita utilizaruna 
gestion de configuraciones estricta. Lagestion de conflguraciones esta relacionada con la ges- 
tion de los cambios del software y con la realizacion de un seguimiento de las versiones de 
un sistema y sus componentes. Este tema se trata en el Capitulo 29. 

20.2 Programacion confiable 

La programacion confiable implica el uso de tecnicas y construcciones de programacion que 
contribuyen a prevenir y tolerar los defectos. Los defectos en los programas tienen lugar de- 
bido a que los programadores cometen errores. Mientras que algunos errores son debidos a 
malas interpretaciones de la especificacion, otros tienen lugar debido a la complejidad de los 
programas o al uso de construcciones intrinsecamentepropensas a error. Paraalcanzar lacon- 
fiabilidad, sin embargo, seriaprecisorealizardisefios simples, proteger la informacion deac- 
cesos no autorizados y minimizar el uso de construcciones de programacion no seguras. 

Las tecnicas de programacion para laprevencion de defectos se basan en el hecho de que 
hay una distincion entre defectos y fallos de ejecucion. Unfallo de ejecucion es algo que es 
observable para los usuarios de un sistema, mientras que un defecto es una caracteristica in- 
terna del sistema. Si un defecto se manifiesta en un programa en ejecucion, es posible tole- 
rarlo detectandolo y realizando la accion de recuperacion antes de que se convierta en un fa- 
llode ejecucion del sistema. En estaseccion, se analiza el usode las construcciones de manejo 
de excepciones para hacer que los programas sean mas tolerantes a defectos y mas faciles de 
comprender. 

20.2.1 Informaclon proteglda 

Un principio sobre proteccion que se adopta en organizaciones militares es el principio de la 
«necesidad de conocer». Solo a aquellos individuos que necesitan conoceruna parte concre- 
tade la informacion para llevar a cabo sucometido se lesproporcionadicha informacion. La 
informacion que no esta directamente relacionada con su trabajo es desautorizada. 

Cuando se programa, deberia adoptarse un principio analogo para controlar el acceso a 
los datos del sistema. A los componentes del programa se les deberia permitir el acceso so- 
lamente a los datos que necesitan para su implementacion. Pueden protegerse otros datos 
mediante el uso de reglas de ambito del lenguaje de programacion para ocultarlos desde 
otras partes del programa. Si se oculta informacion, esta no puede ser viciada por los com- 
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ponentes del programa que se supone que no la utilizan. Si la interfaz sigue siendo la mis- 
ma, la representacion de los datos puede cambiarse sin afectar a otros componentes en el 
sistema. 

La proteccion de la informacion es mucho mas sencilla en Java que en lenguajes mas an- 
tiguos como C o Pascal. Debido a que estos lenguajes no tienen construcciones de encapsu- 
lacion tales como clases de objetos, los detalles de la implementacion de las estructuras de da- 
tos no pueden ser protegidos. Otras partes del programa pueden acceder a la estructura 
directamente, lo que produce efectos secundarios no esperados cuando se realizan cambios. 

Generalmente es una buena practica, cuando se programa en un lenguaje orientado a ob- 
jetos, proporcionar metodos que acceden y actualizan los valores de los atributos en lugar de 
permitir que otros objetos accedan a estos atributos directamente. Esto significa que puede 
cambiarse la representacion del atributo sin preocuparse de como otros objetos utilizan el atri- 
buto. Es particularmente importante utilizar esta aproximacion para estructuras de datos y 
otros atributos complejos. 

La construccion de definiciones de interfaces Java hace posible utilizar esta aproximacion 
y es posible declarar la interfaz de un objeto sin hacer referencia a su implementacion. Esto 
se ilustra en la Figura 20.3. Los usuarios de los objetos de tipo Queue pueden insertar obje- 
tos en la cola, eliminarlos de la cola y consultar el tamafio de la cola. Sin embargo, en la cla- 
se que implementa esta interfaz, la implementacion real de la cola deberia ocultarse decla- 
rando los atributos y metodos como particulares de esa clase de objetos. La separacion de las 
interfaces y su implementacion es una parte esencial de la ingenieria del software basada en 
componentes. 

Otro tipo de proteccion de informacion se ilustra en la Figura 20.4. En situaciones en las 
que un conjunto de valores limitado puede asignarse a alguna variable, estos valores debe- 
rian declararse como constantes. Lenguajes tales como C++ soportan tipos enumerados, 
pero en Java esto debe implementarse asociando estas restricciones con la declaracion de 
la clase. 

Por ejemplo, consideremos un sistema de seftalizacion, implementado en Java, que sopor- 
te luces rojas, ambar y verdes. Deberia definirse un tipo Signal que incluya declaraciones de 
constantes que reflejen estos colores. Por lo tanto, es posible hacer referencia a Signal. red, 
Signal. green y asi sucesivamente. Esto evita asignaciones accidentales de valores incorrectos 



interface Queue { 

Figura 20.3 Una public void put (Object o) ; 

especificacion de publfc void remove (Object o) ; 

una Cola utilizando public int size 0 ; 



una declaracion de 
interfaz Java. 



} //Queue 



dass Signal { 

static public final mt red » i ; 

Figura 20.4 Una Stt*fe|f^feflrrrtlirttaflnb»r»«2 ; 

declaracion de una SWfc^Mbfic final jntgrcep*»£ ; 

Serial en Java que 

oculta el tipo de 0Uw s v , 

representacion. 
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a las variables de tipo Signal. Por lo tanto, se estan protegiendo variables de tipo Signal de 
asignaciones incorrectas y, al mismo tiempo, ocultando la representacion de rojo, ambar y ver- 
de. Pueden cambiarse estos valores constantes mas tarde sin tener que realizar ningun otro 
cambio en el programa. 

20.2.2 Programaclon segura 

Los defectos en los programas, y por lo tanto muchos fallos de ejecucion de estos, son nor- 
malmente consecuencia de un error humano. Los programadores cometen errores debido a 
que pierden la pista de todas las relaciones entre las variables de estado. Escriben senten- 
cias de programas que provocan un comportamiento inesperado y cambios en el estado del 
sistema. Las personas siempre cometeran errores, pero fue evidente a finales de la decada 
de los 60 que algunas aproximaciones de programacion eran mas propensas a error que 
otras. 

Dijkstra (Dijkstra, 1968) reconocio que la sentencia goto o salto incondicional era una 
construccion de programacion intrinsecamente propensa a error. Hace dificil localizar los 
cambios de estado. Esta observacion condujo al desarrollo de la programacion estructurada. 
La programacion estructurada es la programacion sin sentencias goto, utilizando solamente 
bucles while y sentencias if como construcciones de control y un diseflo mediante una apro- 
ximacion descendente. La programacion estructurada fue un hito importante en el desarrollo 
de la ingenieria del software debido a que fue el primer paso hacia una aproximacion disci- 
plinada del desarrollo del software. 

Otras construcciones de lenguajes de programacion y tecnicas de programacion son tam- 
bien intrinsecamente propensas a error. Es menos probable introducir defectos en los progra- 
mas si se evitan o, al menos, se usan lo menos posible. Las construcciones potencialmente pro- 
pensas a error comprenden: 

1. Numeros en coma flotante. Los numeros en coma flotante son intrinsecamente im- 
precisos. Este es un problema particular cuando hay comparaciones debido a que la 
imprecision en la representacion puede llevar a comparaciones incorrectas. Por ejem- 
plo, 3,00000000 a veces puede representarse como 2,99999999 y a veces como 
3,00000001 . Una comparacion podria mostrar estos valores como distintos. Los nu- 
meros en coma fija, que son aquellos en los que un numero se representa con un nu- 
mero determinado de posiciones decimales, son mas seguros debido a que son posi- 
bles las comparaciones exactas. 

2. Punteros. Los punteros son construcciones de bajo nivel que almacenan direcciones 
que hacen referencia directamente a zonas de memoria de la maquina. Los errores en 
su uso pueden ser devastadores, debido a que permiten aliasing (explicado mas ade- 
lante en esta lista) y debido a que pueden hacer mas dificil de implementar la com- 
probacion de los limites de los vectores y de otras estructuras. 

3. Asignacion dindmica de memoria. La memoria del programa puede asignarse en 
tiempo de ejecucion en lugar de en tiempo de compilacion. El peligro de esto es que 
la memoria puede no liberarse de forma que eventualmente el sistema puede quedarse 
sin memoria disponible. Este puede ser un error muy dificil de detectar debido a que 
el sistema puede ejecutarse con exito durante un periodo de tiempo largo antes de que 
surja ningun problema. 

4. Paralelismo. El paralelismo es peligroso debido a las dificultades de predecir los 
efectos sutiles de las interacciones temporales entre los procesos en paralelo. Los pro- 
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blemas temporales normalmente no pueden detectarse mediante la inspeccion de 
programas, y lapeculiarcombinacion de circunstancias que ocasionan un problema 
temporal puede no darse durante la prueba del sistema. El paralelismo puede ser in- 
evitable, pero su uso deberia ser cuidadosamente controlado para minimizar las de- 
pendencias entre los procesos. Las facilidades de los lenguajes de programacion ta- 
les como los hilos de ejecucion (threads) de Java ayudan a gestionar el paralelismo 
para que puedan evitarse algunos errores de programacion. 

5. Recursion. La recursion se produce cuando un procedimiento o metodo se llama a si 
mismo o llama a otro procedimiento, el cual a su vez llama al procedimiento origi- 
nal que realizo la llamada. Su uso puede generar programas concisos, pero puede ser 
dificil seguir la logica de los programas recursivos. Por lo tanto, los errores de pro- 
gramacion son mas dificiles de detectar. Los errores de recursion pueden provocar la 
asignacion de toda la memoria del sistema a medida que se crean las variables tem- 
porales de la pila. 

6. Interrupciones. Son un modo de forzar la transferencia de control a una seccion de 
codigo independientemente del codigo que se este ejecutando actualmente. Los pe- 
ligros de esto son evidentes: la interrupcion puede provocar la terminacion de una 
operacion critica. 

7. Herencia. El problema de la herencia en la programacion orientada a objetos es que 
el codigo asociado con un objeto no esta todo en un mismo sitio. Esto hace mas di- 
ficil comprender el comportamiento del objeto. Por lo tanto, es mas probable que 
los errores de programacion no se encuentren. Ademas, la herencia cuando se com- 
bina con el enlace dinamico puede provocar problemas temporales en tiempo de eje- 
cucion. En diferentes momentos, podrian llamarse a distintas instancias de un me- 
todo especifico y se consumirian tiempos diferentes buscando la instancia correcta 
del metodo. 

8. Aliasing. Esto ocurre cuando se utiliza mas de un nombre para referirse a la misma 
entidad en un programa. Es facil para los lectores de los programas omitir sentencias 
que cambian la entidad cuando tienen que considerar varios nombres. 

9. Vectores no limitados. En lenguajes tales como C, los vectores son simplemente for- 
mas de acceder a la memoria, y pueden hacerse asignaciones mas alia del final de un 
vector. El soporte de ejecucion del sistema no comprueba que las asignaciones real- 
mente se refieren a los elementos del vector. Una vulnerabilidad conocida de la pro- 
teccion es el desbordamiento del bufer, en el que un intruso deliberadamente cons- 
truye un programa para escribir en la memoria mas alia del final de un bufer que se 
implementa como un vector. 

1 0. Procesamiento de entradas por defecto. Algunos sistemas proporcionan un proce- 
samiento de las entradas por defecto independientemente de la entrada presentada 
al sistema. Esto es un agujero en la proteccion que un intruso puede aprovechar 
para presentar al programa entradas no esperadas y que no sean rechazadas por el 
sistema. 

Algunos estandares para el desarrollo de sistemas de seguridad criticosprohiben comple- 
tamente el uso de estas construcciones. Sin embargo, esta posicion extrema no es normal- 
mente practica. Todas estas construcciones y tecnicas son utiles, pero tienen que utilizarse con 
cuidado. Siempre y cuando sea posible, sus potenciales efectos peligrosos deberian contro- 
larse utilizandolos dentro de tipos abstractos de datos u objetos. Estos actuan como «corta- 
fuegos» limitando el dano ocasionado si se producen errores. 
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Los disenadores de Java han reconocido algunos de los problemas de las construcciones 
propensas a error. El lenguaje no incluye sentencias goto, utiliza un recolector de basura de 
manera que no necesita asignar memoria de forma dinamica, y no soporta punteros o vecto- 
res no limitados. Sin embargo, larepresentacion numericade Java es tal que el soporte de eje- 
cucion del sistema no detecta desbordamiento de memoria, y todavia son posibles fallos de 
ejecucion debidos a errores de operaciones en punto flotante. 

20.2.3 Manejo de excepclones 

Durante la ejecucion del programa, los errores o eventos no esperados ocurren inevitable- 
mente. Esto puede darse debido a un defecto en el programa o puede ser el resultado de cir- 
cunstancias externas no predecibles. Un error o un evento inesperado que ocurra durante la 
ejecucion de un programa se denomina una exception. Las excepciones pueden serprovoca- 
das por condiciones hardware o software. Ejemplos de excepciones podrian ser un fallo en el 
suministro de energia al sistema, un intento de acceso a datos no existentes, y desbordamien- 
to de memoria numerico. 

Cuando ocurre una excepcion, esta debe ser manejada por el sistema. Esto puede hacerse 
dentro del mismo programa o puede implicar la transferencia de control a un mecanismo de 
manejo de excepciones del sistema. Normalmente, el mecanismo de manejo de excepciones 
del sistema simplemente informa del error y abandona la ejecucion. Por lo tanto, para asegu- 
rarque las excepciones del programa no provocan fallos de ejecucion del sistema, deberiade- 
finirse un manejador de excepciones para todas las posibles excepciones que puedan ocurrir 
y asegurarse de que todas las excepciones se manejan de forma explicita. 

En lenguajes de programacion tales como C, las sentencias if deben utilizarse para de- 
tectar la excepcion y transferir el control al codigo de manejo de excepciones. Esto signifi- 
ca que se tienen que comprobar explicitamente las excepciones en cualquier sitio en el pro- 
grama en donde puedan ocurrir. Sin embargo, esto afiade complejidad y, por lo tanto, 
incrementa la probabilidad de que se cometan errores y de que la excepcion no sea maneja- 
da correctamente. 

Algunos lenguajes de programacion, como Java, C++ y Ada, incluyen construcciones que 
soportan el manejo de excepciones de forma que no se necesitan sentencias condicionales adi- 
cionales para comprobar las excepciones. En su lugar, el lenguaje de programacion incluye 
un tipo de construccion especial (a menudo denominado Exception), y diferentes excepcio- 
nes pueden declararse con este tipo. Cuando ocurre una situacion excepcional, la excepcion 
es capturada y el soporte de ej ecucion del lenguaje transfiere el control a un manejador de ex- 
cepciones. Este es una seccion de codigo que declara los nombres de las excepciones y las ac- 
ciones adecuadas para manejar cada excepcion. 

En Java, pueden declararse nuevos tipos de excepciones extendiendo la clase Exception. 
Las excepciones son provocadas en Java utilizando una sentencia th row. El manejador de una 
excepcion se indica por la palabra clave catch, seguida por un bloque de codigo que maneja 
la excepcion. 

La Figura 20.5 ilustra el uso de las excepciones en Java. Este ejemplo, parte del software 
para la bomba de insulina introducida en el Capitulo 3, es un controlador de un sensor que lee 
el valor de la glucosa en la sangre desde un sensor. La primera declaracion en la Figura 20.5 
muestra como se declaran las excepciones en Java. Se extiende la clase de objetos denomi- 
nada Exception, y el constructor del metodo define el codigo a implementar cuando la ex- 
cepcion es provocada. En este caso, se activa una alarma. 
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dass SensoffaflureException extends Exception { 

SensorFailureException (String msg) { 
super (msg) ; 
Alamucthnte (msg) ; 

} 

} // Sensoffaiki re Exception 
dass Sensor { 

int readVal 0 throws SensorFailureException { 

try{ 

int the Value «= Device lO.readlnteger 0 ; 
if (theValue<0) 

throw new SensorFailureException ("Sensor failure') ; 
return theVahie ; 

J 

catch (devicetOExce prion e) 
{ 

throw new SensorFailureException (" Sensor read error *) ; 

} 

} //readVal 
} //Sensor 



Figura 20.5 
Excepciones para 
manejar fallos de 
ejecucion en la 
bomba de insulina. 



Laclase Sensor proporciona un unico metodo denominado readVal, que incluye una sen- 
tencia throw en sudeclaracion. Eslo significaque una SensorFailureException puede sercap- 
turada desde dentro del metodo, pero el metodo que hace la llamada se espera que proporcione 
un manejador para SensorFailureException. Normalmente es mejor manejar las excepciones 
en el metodo que hace la llamada debido a que este metodo conoce lo que se pretende hacer 
con el resultado del metodo al que se llama. Sin embargo, como se muestra mas adelante, hay 
algunas situaciones en las que las excepciones se manejan localmente para asegurar que el re- 
sultado de una llamada a un metodo es siempre valido. 

La palabra clave try indica que puede provocarse una excepcion en el siguiente bloque de 
codigo. Laexcepcion SensorFailureException se lanza si un valor menor que cero es devuelto 
cuando se comprueba el sensor. DevicelO. read Integer puede lanzar una excepcion denomi- 
nada device 10 Exception, por lo que a continuacion de la palabra clave catch tambien debe- 
ria incluirse un manejador para esta excepcion. En este caso, el manejador simplemente pro- 
voca una excepcion de fallo de ejecucion de sensor para indicar que el objeto que realiza la 
llamada deberia manejar la excepcion. 

El manejo de excepciones tambien puede utilizarse para simplificar los programas y ha- 
cerlos mas faciles de leer y entender. Esto reduce la probabilidad de error del programador e 
incrementa la posibilidad de que los inspectores de programas encuentren cualquier proble- 
ma que exista. El manejo de excepciones se utiliza para separar el codigo de manejo de error 
del codigo que maneja el procesamiento normal. Por lo tanto, es posible leer y comprender 
cada una de estas secciones del codigo por separado. 

Esto se ha ilustrado en la Figura 20.6. Esta clase Java es una implementacion de un con- 
trolador de temperatura de un congelador de comida. La temperatura requerida puede fljarse 
entre - 1 8 y — 40 grados Celsius. La comida congelada puede comenzar a descongelarse y las 
bacterias se vuelven activas a temperaturas por encima de — 18 grados. El sistema de control 
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riMttiCwibuNcf { 



Sensor tempSensor » new Sensor 0 ; 
Dial tempDiai- new Dial 0; 
float freezetfemp-tempSensofjeadMO; 
final float dangerTamp - (float) -18JJ ; 
final tang cootrogTime - (long) 2000000 ; 

public void run ( ) throws IntefruptedException { 
try{ 

Pumpswitchtt (Pumpxm) ; 
dot 

if (fnwzerTemp > tempDial .setting 0) 
if (Pump.status — Pump.off) 



( 



PumpjwRxhtt (Pumpxm) ; 
ThreadsJeep (cooingTime) ; 



Flgura 20.6 

Excepciones en un 
controlador de 
temperatura de un 
congelador. 



if (Pump .status — Pump.on) 
Pump.switehtt (Pump.o(f) ; 

if (freezerTemp > dangerTemp) 

throw new ReezerTooHotExcepbon 0 ; 
freezerTemp - tempSensomadVal 0 ; 

) white (true); 

}//try bfodc 

catch (FreeiefTooHotExceptior) f) 

{AlanrtactwateO;} 

catch (krterrupted Exception e) 

{ 



} 



SystenuNitprintln (Thread exception") ; 
throw new tntenuptedException ( ) ; 



}//nm 
J // ReezeiCorrtroHer 



mantiene esta temperatura alternando el encendido y apagado de una bomba refrigerante de 
acuerdo con el valor de un sensor de temperatura. Si la temperatura requerida no puede man- 
tenerse, el controlador dispara una alarma. 

En la implementacion Java, la temperatura del congelador se obtiene interrogando a un ob- 
jeto denominado tempSensor, y la temperatura requerida se obtiene inspeccionando un ob- 
jeto denominado tempDial. Un objeto bomba (Pump) responde a las senales para cambiar su 
estado. Una vez que la bomba ha sido encendida, el sistema espera durante algun tiempo (11a- 
mando a Thread. sleep) para que la temperatura se reduzca. Si no ha disminuido suficiente- 
mente, se lanza una excepcion denominada FreezerTooHotException. 

El manejador de excepciones (situado al final del codigo) captura esta excepcion y activa 
el objeto Alarm. Tambien se incluye un manejador para la excepcion InterrupmtedException, 
que puede ser provocada por Thread. sleep. Este registra la excepcion, y a continuacion vuel- 
ve a provocar la excepcion para su manejo en el metodo principal. 
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20.3 Tolerancia a defectos 

Un sistema tolerante a defectos puede continuar en funcionamiento despues de que se mani- 
fiesten algunos defectos en el programa. Los mecanismos de tolerancia a defectos en el sis- 
tema aseguran que estos defectos del sistema no provocan fallos de funcionamiento del siste- 
ma. Se necesita tolerancia a defectos en situaciones en las que un fallo de funcionamiento del 
sistema podriaprovocarun accidente catastrofico o en las queunaperdida de funcionamien- 
to del sistema pudiese causar grandes perdidas economicas. Por ejemplo, las computadoras 
de un avion deben estar en funcionamiento hasta que el avion aterrice; las computadoras en 
un sistema de trafico aereo deben estar disponibles continuamente mientras los aviones esten 
en el aire. 

Existen cuatro aspectos a considerar en la tolerancia a defectos: 

1. Detection de defectos. El sistema debe detectar un defecto que podria conducir a un 
fallo deejecuciondel sistema. Generalmente, esto implicacomprobarqueelestadodel 
sistema es consistente. 

2. Evaluation de ios dahos. Se deben detectar las partes del estado del sistema que han 
sido afectadas por el defecto. 

3. Recuperation de defectos. El sistema debe restaurar su estado a un estado «seguro» 
conocido. Esto puede conseguirse corrigiendo el estado danado (recuperacion de erro- 
res hacia adelante) o restaurando el sistema a un estado «seguro» conocido (recupe- 
racion de errores hacia atras). 

4. Reparation de defectos. Esto implica modificar el sistema para que no vuelva a apa- 
recer el defecto. Sin embargo, muchos defectos del software se manifiestan como es- 
tados transitorios. Ello se debe a una comb inacion peculiar de entradasdel sistema. No 
es necesario realizar ninguna reparacion y el procesamiento normal puede continuar- 
se inmediatamente despues de la recuperacion de los defectos. 

Podria pensarse que las facilidades para la tolerancia a defectos son innecesarias en sis- 
temas que han sido desarrollados utilizando tecnicas que evitan la introduccion de defec- 
tos. Si no hay defectos en el sistema, podria parecer que no hay ninguna posibilidad de un 
fallo de ejecucion del sistema. Sin embargo, «libre de defectos» no significa «libre de fa- 
llos de ejecucion». Tan solo significa que el programa se corresponde con su especificacion. 
La especificacion puede contener errores u omisiones y puede estar basada en suposiciones 
incorrectas sobre el entorno del sistema. Y, desde luego, nosotros nunca podemos demos- 
trar de forma concluyeme que un sistema esta completamente libre de defectos. En los sis- 
temas que tienen los requerimientos mas altos de fiabilidad y disponibilidad, se necesita uti- 
lizar redundancia y diversas aproximaciones de prevencion de defectos y de tolerancia a 
defectos. 

20.3.1 Detecclon de defectos y evaluation de danos 

La primera etapa de la tolerancia a defectos es detectar que un defecto (un estado del sistema 
erroneo) o bien ha ocurrido u ocurrira a menos que se realice inmediatamente alguna accion. 
Para hacer esto, se necesita conocercuando el valor de una variable de estado es ilegal o cuan- 
do las relaciones entre variables de estado no se mantienen. Por lo tanto, se necesita definir 
restricciones de los estados que determinan las condiciones que deberian cumplirse para to- 
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dos los estados legales. Si estos predicados son falsos, entonces ha tenido lugar un defecto. 
Algunos ejemplos de restricciones de estados que se aplican al software de la bomba de in- 
sulina se muestran en la Figura 20.7. De forma deliberada no se han escrito estas restriccio- 
nes como sentencias de aserciones Java por las razones que se explicaran mas adelante. 
Existen dos tipos de deleccion de defectos que se pueden utilizar: 

1. Detection de defectos preventiva. En este caso, el mecanismo de deteccion de defec- 
tos se inicia antes de que se produzca un cambio en el estado. Si se detecla un estado 
potencialmente erroneo, entonces el cambio de estado no se realiza. 

2. Detection de defectos retrospectiva. En este caso, el mecanismo de deteccion de de- 
fectos se inicia despues de que el estado del sistema ha sido cambiado para compro- 
bar si ha tenido lugar un defecto. Si se descubre un defecto, se provoca una excepcion 
y se utiliza un mecanismo de reparacion para recuperarse de ese defecto. 

Puede utilizarse la deteccion de defectos preventiva cuando las restricciones de los estados 
que han sido definidas se aplican solamente a variables de estados individuates. Porejemplo, 
usted puede utilizar esta aproximacion cuando el valor de una variable de estado debe estar 
dentro de un rango definido. La deteccion de defectos preventiva evita la sobrecarga de la re- 
paracion de un defecto, ya que el estado del sistema siempre sera valido, si bien no necesa- 
riamente correcto. Sin embargo, el sistema debe tener un mecanismo para continuar su fun- 
cionamiento ante la presencia de un estado incorrecto si se quiere evitarun fallo de ejecucion 
del sistema. 

En Java, la forma mas segura de implementar la deteccion de defectos preventiva es com- 
probar de forma explicita la presencia de defectos y utilizar el mecanismo de manejo de ex- 
cepciones en el lenguaje para indicar que un estado erroneo del sistema ha sido detectado. Esto 
se ilustra en la Figura 20.8. Esta es una implementacion de una clase en la que los valores de 
las instancias de la clase son restringidos a numeros positivos pares. Si se hace un intento de 
asignar un numero que es impar o menor que cero, entonces se provoca una excepcion. 

En Java 1.4, se introdujo una facilidad para aserciones cuando las restricciones de los es- 
tados puedan ser definidas con una sentencia assert. Por lo tanto, para especificar que un nu- 
mero deberia ser positivo y par, se deberia escribir: 

assert n >= 0 & n%2 = 0: «Value musi be positive and even» 

El soporte de ejecucion del sistema comprueba que la condicion se cumple y, si no es asi, 
provoca un error y hace que se imprima el mensaje asociado. 

Sin embargo, ta facilidad de aserciones en Java fue disenada realmente para lograr a des- 
cubrir inconsistencias de estados durante el desarrollo y depuracion en lugar de soportarpro- 
gramacion tolerante a defectos. Es posible activar y desactivar la comprobacion de asercio- 
nes, de forma que usted no puede confiar en que las aserciones esten siempre activadas. 



/ 



// The dose of frtsuSn to be delivered must always be greater 
// than zero and tan that some defined maximum single dose 



irtsuKn_<kse >» 0 & insulifudose 0 insulin_reserwoif .contents 



Figura 20.7 

Restricciones de los 
estados que se 
aplican en la bomba 
de insulina. 



// The totei amount of insulin defivwed in a day must be less 
// than or equal to a defined darty maximum dose 



cumulatiw.dose O maxirrHjm_da8y_dose 
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Ademas, no es posible asociar un tipo especifico de excepcion con cada asercion, por lo que 
no pueden identificarse fallos de funcionamiento individuales en las aserciones. Esto fue una 
decision de diseno deliberada; los diseiiadores no pretendian que fuese posible recuperarse de 
una accion despues de que una asercion falle. 

La deteccion de defectos preventiva es posible cuando se conoce el rango de valores que 
pueden asignarse a una variable de estado. Sin embargo, cuando un valor valido depende del 
valor asignado a otras variables en el estado, la deteccion de defectos preventiva puede ser im- 
posible. Por ejemplo, supongamos que el programa lee tres valores, A, B y C, en ese orden. 
La restriccion del estado es: 

A< B& B<C 

No puede aplicarse la deteccion de defectos preventiva cuando se lea el valor de A debido 
a que no se conoce cual sera el valor de B y C. Del mismo modo, cuando se lea B, no se pue- 
de comprobar que es menor que C. Por lo tanto, necesita utilizar la deteccion de defectos re- 
trospectiva, comprobando la restriccion del estado despues de que todos los valores hayan sido 
leidos. Si la restriccion es falsa, entonces se puede realizar alguna accion para restaurar la con- 
sistencia del sistema. 

Una forma de implementar la deteccion de defectos retrospectiva en Java consiste en aso- 
ciar una funcion de comprobacion con un objeto. Esta funcion puede llamarse despues de que 
los cambios en el estado hayan tenido lugar para asegurar que se cumplen las restricciones del 



dass Fn ri t weEwfa lBget { 

intval-0; 

PosWveBvenlrrtegef (in* n) (throws -MumericException 

* fc<(wybl|tfl«zs=ii) 

threw raw NHmerjffix«¥^winQ>; 

eke 

^/iRositiveEvenlHteger 

puWit TOidiassign. (int n)tthtQwsrttumeffi£xc^p£wii 
I 

threw ntw NwfteBSsfi^tjWkO; 

tlie 

{ 

return vah; 
)///!WSpff 

boolean equate (PosftwefiveiiiJiitegjei n) 

I 

return (nali— •Bjral) ; 
} // equals 

} //PosittveEven 



Figura 20.8 Clase 
Positive Evenlnteger 
en Java. 
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estado. Estas pueden llamarse cuando sea necesario — puede que no se necesite comprobar el 
estado despues de que cada cambio haya tenido lugar — . La siguiente interfaz puede ser uti- 
lizada para funciones de comprobacion: 

interface CheckableObject { 
public boolean check(); 

} 

Los objetos a comprobar son instancias de una clase de objetos que jmplementa esta in- 
terfaz, por lo que cada objeto tiene una funcion de comprobacion asociada. Cada clase de ob- 
jetos implementa su propia funcion de comprobacion que define las restricciones particula- 
res que se aplican a los objetos de esa clase. Cuando se comprueba un estado en su totalidad, 
se utiliza enlace dinamico para asegurarque se aplica la funcion de comprobacion adecuada 
para la clase del objeto que se esta comprobando. Puede verse un ejemplo de esto en la Figu- 
ra 20.9, en donde la funcion check comprueba que los elementos de un vector satisfacen al- 
guna restriccion. 

La deteccion de defectos retrospectiva, que utiliza restricciones de estados que se aplican 
a mas de una variable de estado, se ilustra en la Figura 20.10. En este ejemplo, la comproba- 
cion de deteccion de defectos se aplica a elementos consecutivos de un vector y comprueba 
que el vector este ordenado. 



dass RobustArray { 

// Checks that all the objects in an array of objects 
// conform to some defined constraint 

boolean Q checkState ; 
CheckableObject Q theRobustArray ; 

RobustArray (CheckableObject Q theArray) 
{ 

checkState - new boolean pheArray.length] ; 
theRobusMiny~ theArray; 
} //RobustArray 

public void assessDamage 0 throws ArrayDamafled Exception 
{ 

boolean hasBeen Damaged - false ; 

for (irrt ^ 0; i <3h is.theRobustAirgy.1 ength ; i ++) 
{ 

if (I theRobustArray [fl.check 0) 
{ 

checkState [i] - true ; 
hasBeenDarnaged - true ; 

> 

else 

checkState p]- false ; 

} 

if (hasBeenDarnaged) 
^_thniw new ArrayDatnagedException 0 ; 

j^^heck^tfrat^?^he objects in an array of objects 
some defined constraint 



boolean ft checkState; 
Otedudrf eObject D tiwRobustAjray; 
RobustArray (CheckableObject Q theArray) 
{ 

ttguta*»«tt^aiahos. ,// n wtimM&fajmM iffl*m)il\mf"m iwtfta Mflxceptton 
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La evaluacion de danos implica analizar el estado del sistema para estimar el alcance de la 
corrupcion del estado. La evaluacion de danos es necesaria cuando no se puede evitar reali- 
zar un cambio de estado o cuando un defecto tiene lugar por una secuencia invalida de cam- 
bios de estado correctos individualmente. 

El papel de los procedimientos de evaluacion de danos no es recuperarse del defecto sino 
evaluar que partes del espacio de estados han sido afectadas por el defecto. Los danos solo 
pueden serevaluados si es posibleaplicar alguna «funcionde validacion» que compruebaque 
el estado es inconsistente. Si se encuentran inconsistencias, estas son resaltadas o indicadas 
de alguna manera. 

La Figura 20.9 muestra una forma de implementar la evaluacion de danos en Java. La es- 
tructura de datos denominada RobustArray es una coleccion de objetos de tipo Checkable- 
Object. La clase que implementa el tipo CheckableObject debe incluir un metodo denomi- 
nado check que pueda probar si el valor del objeto satisface alguna restriccion. Este metodo 
decomprobacion se asociacon este objeto en lugar de con el objeto RobustArraydebidoaque 
los detalles de lacomprobaciondependendeluso del tipo CheckableObject. 

El metodo assessDamage en la clase RobustArray examina cada elemento del vectory 
compruebaque su estado es correcto. Si uno o mas elementos del vector no satisfacen las res- 
tricciones del estado definidas en la funcion check, entonces los elementos daiiados se regis- 
tran en el vectorcheckState. A continuacion se lanzaunaexcepcion denominadaArrayDa- 
mageException. Se debe incluir en el metodo que realiza la llamadaun manejadorpara esta 
excepcion que gestione el dano. Este puede utilizar la informacion en checkState para deci- 
dir lo que hay que hacer. 



dass SafeSort { 

sialic void sort ( int Q mtarray, kit order ) throws SortError 
{ 

int Q copy » new int fmtarray.length]; 

// copy the input array 

for (ml i «■ 0; i < mtarray jertgth ; r++) 
copy [i] - intarray [i] ; 

Sorlbubbtesort (irdarray, intarray. length, order) ; 
if (order — Sortascerxfing) 

for ("mt i — 0; i O* intanay.lenglh-2 ; t++) 
if Ontarray HI > intarray 
throw new SortError 0 ; 

else 

for (mt i » 0; i <» intarrayJength-2 ; 
if (intarray ft+1] > intarray 0) 
throw new SortEnor 0 ; 

}//tiybiock 
catch (SortError e) 
{ 

for (mt i « 0; i < intarrayJength ; i++) 
Figura 20.10 intarray fj] - copy 0 ; 

throw new SortError ("Array not sorted*) ; 
}//cateh 
}//sort 

con recuperac.on de J//SafeSort 
errores hacia atras. 
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Otras tecnicas de deteccion de defectos y de evaluacion de danos dependen de la repre- 
sentacion de los estados del sistema y del tipo de aplicacion. Estas tecnicas de evaluacion de 
danos incluyen: 

1. El uso de comprobaciones de codigo y sumas de verificacion en las comunicaciones 
de datos y comprobaciones de digitos en datos numericos. 

2. El uso de enlaces redundantes en estructuras de datos que contienen punteros. 

3. El uso de temporizadores en sistemas concurrentes. 

Las comprobaciones de codigo (Fujiwara y Pradhan, 1990) pueden utilizarse cuando los 
datos son intercambiados y en los que una suma de verificacion se asocia con los datos nu- 
mericos. Una sumade verificacion es un valor unico que se calcula aplicando alguna funcion 
matematica a los datos. Esta sumade verificacion es calculadaporel emisor, que aplica la fun- 
cion de suma de verificacion a los datos y anade el valor de esa funcion a los dalos a transfe- 
rir. El receptor aplica la misma funcion a los datos y compara el valor calculado con la suma 
de verificacion anadida. Como las funciones son las mismas, si estos valores difieren, enton- 
ces el propio dato tiene que haber cambiado. Esta tecnica puede utilizarse para detectar in- 
trusiones en la proteccion asi como corrupciones de los datos accidentales o deliberadas. 

Cuando se utilizan estructuras enlazadas de datos, la representacion puede hacerse redun- 
dante incluyendo referencias hacia atras. Es decir, para cada referencia desde A hasta B, exis- 
te una referencia comparable desde B hasta A. Tambien se puede contar el numero de ele- 
mentos en la estructura. La comprobacion puede determinar si las referencias hacia adelante 
y hacia atras son consistentes (estas deberian referirse la una a la otra) y si el tamano de la es- 
tructura calculado es el mismo. 

Cuando los procesos deben reaccionar dentro de un periodo de tiempo especifico, puede 
instalarse un temporizador de vigilancia. Un temporizador de vigilancia es un temporizador 
que debe reinicializarse por el proceso en ejecucion cuando se completa su accion. Comien- 
za al mismo tiempo que un proceso,.y temporiza la ejecucion del proceso. Un controlador pue- 
de consultarlo a intervalos regulares. Si, por alguna razon, el proceso fallaen su terminacion, 
el temporizador de vigilancia no se reinicializa. Por lo tanto, el controlador puede detectar que 
ha surgido un problema y realizar alguna accion para forzar la terminacion del proceso. 

20.3.2 Recuperaclon y reparaclon de defectos 

La recuperacion de defectos es el proceso de modificarel espacio de estados del sistema para 
que los efectos del defecto sean eliminados o reducidos. El sistema puede continuar funcio- 
nando, quizas de forma algo degradada. La recuperacion hacia adelante implica intentar co- 
rregir el sistema dafiado y crear el estado esperado. La recuperacion hacia atras restaura el 
estado del sistema a un estado «correcto» conocido. 

La recuperacion de errores hacia adelante solo es posible en situaciones en las que la in- 
formacion del estado incluye redundancia. Existen dos situaciones generales (ambas descri- 
tas en la seccion previa) en las que pueden aplicarse tecnicas de recuperacion de errores: 

1. Cuando ;os datos del codigo estdn dahados. El uso de tecnicas de codificacion que 
aiiaden redundancia a los datos permite corregir los errores asi como detectarlos. 

2. Cuando ;as estructuras enlazadas estdn dahadas. Cuando los punteros hacia ade- 
lante y hacia atras se incluyen en la estructura de datos, la estructura puede volverse 
a crear — si un numero suficiente de punteros permanece sin danar — . Esta tecnica 
se utiliza frecuentemente para sistemas de ficheros y reparacion de bases de datos. 
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La recuperacion de errores hacia atras es una tecnica mas simple que restaura el estado a 
un estado seguro conocido despues de haberse detectado un error. La mayoria de los sistemas 
de bases de datos incluyen recuperacion de errores hacia atras. Cuando un usuario inicia un 
calculo en la base de datos, se inicia una transaccion. Los cambios realizados durante esa 
transaccion no se incorporan inmediatamente en la base de datos. La base de datos solo se ac- 
tualiza despues de que la transaccion termine y no se haya detectado ningun problema. Si la 
transaccion falla, la base de datos no se actualiza. 

Las transacciones permiten la recuperacion de errores puesto que no realizan cambios en 
la base de datos hasta que se han completado. Sin embargo, no permiten recuperacion de cam- 
bios de estados que son validos pero incorrectos. Los puntos de comprobacion es una tecni- 
ca que puede recuperarse de esta situacion. El estado del sistema se duplica periodicamente. 
Cuando se descubre un problema, un estado correcto puede restaurarse a partir de una de es- 
tas copias. 

Como ejemplo de como puede implementarse la recuperacion hacia atras utilizando pun- 
tos de comprobacion, consideremos la clase Java SafeSort mostrada en la Figura 20.10 que 
incluye codigo para la deteccion de errores y recuperacion hacia atras . 

El metodo crea un punto de comprobacion copiando el vector antes de la operacion de 
ordenacion. En este ejemplo, se utilizapor simplicidad una ordenacion de burbuja, pero ob- 
viamente puede utilizarse cualquier algoritmo de ordenacion. Si hay un error en el algorit- 
mo de ordenacion y el vector no esta correctamente ordenado, esto se detecta mediante 
comprobaciones explicitas del orden de los elementos en el vector. Si el vector no esta co- 
rrectamente ordenado, se provoca una excepcion SortException. El manejador de excep- 
ciones no intenta reparar el problema, sino que restaura el valor original del vector y relanza 
SortErrorpara indicar al metodo que realiza la llamada que la ordenacion no ha tenido exi- 
to. Es entonces responsabilidad del metodo que realiza la llamada el decidir como continuar 
la ejecucion. 

Como se ha sugerido antes, muchos defectos del software son transitorios, y no se requie- 
re una reparacion explicita para corregir las condiciones que provocan tales defectos. Estos 
desaparecen en una ejecucion posterior del sistema. En donde no se de el caso, es posible lle- 
var a cabo alguna accion reparadora. La accion reparadora del software mas usual es reini- 
cializar el sistema, reinicializando el estado a sus valores iniciales seguros (Huang y Kintala, 
1993). A veces, esto puede realizarse sin parar el sistema si la inicializacion es rapida y las 
peticiones de servicio pueden posponerse. Otras alternativas de reparacion, como la reconfi- 
guracion dinamica, normalmente solo son posibles cuando se ha hecho una provision expli- 
cita desde el diseno del sistema. 

20.4 Arquitecturas tolerantes a defectos 

En muchos sistemas, es posible implementar la tolerancia a defectos del software incluyendo 
de forma explicita comprobaciones y acciones de recuperacion en el software. Esto se deno- 
mina programacion defensiva. Sin embargo, esta aproximacion no puede tratar de forma efec- 
tiva los defectos del sistema que tienen lugar a partir de interacciones entre el hardware y el 
software. Ademas, un mal entendimiento de los requerimientos puede implicar que tanto el 
codigo del sistema como la defensa asociada sean incorrectos. 

Para la mayoria de los sistemas criticos, en particular aquellos con requerimientos de dis- 
ponibilidad restringidos, puede necesitarse una arquitectura especifica del sistema disenada 
para soportar la tolerancia a defectos. Ejemplos de sistemas que utilizan esta aproximacion 
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de tolerancia a defectos son los sistemas en los aviones que deben estar en funcionamiento 
durante todo el vuelo, los sistemas de telecomunicaciones y los sistemas criticos de ordenes 
y control. Pullum (Pullum, 2001) describe diferentes tipos de arquitecturas tolerantes a de- 
fectos que han sido propuestas. 

Durante muchos anos ha habido una necesidad de construir hardware tolerante a defectos. 
La tecnica mas comunmente utilizada de tolerancia a defectos hardware esta basada en la no- 
cion de redundancia modular triple (TMR) . Launidad hardware se reproduce tres veces (o al- 
gunas veces mas) . La salida de cada unidad se envia a un comparador de salidas que normal- 
mente se implementa como un sistema de votaciones. Si una de las unidades falla y no 
produce la misma salida que el resto de las unidades, se pasa por alto su salida. Un gestor de 
defectos puede intentar reparar la unidad defectuosa de forma automatica, pero si esto es im- 
posible, el sistema se reconnguraautomaticamente para dejar fuerade servicio esa unidad. Se- 
guidamente el sistema continua funcionando con dos unidades {Figura 20. 11). 

Esta aproximacion a la tolerancia a defectos cubre la mayoria de los fallos de ejecucion del 
hardware que son el resultado de fallos en los componentes en lugarde defectos de diseno. 
Por lo tanto, es probable que los componentes fallen de forma independiente. Se supone que, 
cuando son completamente funcionales, todas las unidades hardware funcionan de acuerdo 
con su especificacion. Por lo tanto, hay una baja probabilidad de fallos simultaneos en los 
componentes en todas las unidades hardware. 

Por supuesto, todos los componentes podrian tener un defecto de diseno y entonces to- 
dos producirian la misma respuesta (erronea). Utilizando unidades hardware que tienen una 
especificacion comun, pero que se han disenado y construido por diferentes fabricantes, se 
reduce la probabilidad de un modo de fallo generalizado de este tipo. Se supone que la pro- 
babilidad de que diferentes grupos cometan el mismo error de fabricacion o diseno es pe- 
quefia. 

Si los requerimientos de disponibilidad y Habilidad de un sistema son tales que se necesi- 
ta utilizar hardware tolerante a defectos, entonces tambien puede necesitarse software tole- 
rante a defectos. Existen dos aproximaciones relacionadas con la provision de software tole- 
rante a defectos (Figuras 20.12 y 20.13). Ambas tecnicas han sido derivadas del modelo 
hardware en el que se incluyen los componentes redundantes (o quizas los sistemas redun- 
dantes) y los componentes defectuosos se dejan fuera de servicio. 

Las dos aproximaciones para la tolerancia a defectos del software son: 

1. Programacion con n-versiones. Utilizando una especificacion comun, el sistema soft- 
ware se implementa en varias versiones por diversos equipos. Estas versiones se eje- 
cutan en paralelo sobre computadoras diferentes. Sus salidas se comparan utilizando 
un sistema de votaciones y las salidas inconsistentes o las que no se producen a tiem- 
po son rechazadas. Al menos deberian estar disponibles tres versiones del sistema para 
que dos versiones fuesen consistentes en el caso de que solo una de ellas fallase. Esta 
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es la aproximacionusada mas comunmente para tolerancia a defectos del software. Ha 
sido utilizada en sistemas de senalizacion de vias ferroviarias, en sistemas de aviones 
y en sistemas de proteccion de reactores. Avizienis (Avizienis, 1985; Avizienis, 1995) 
describe estaaproximacion. 
2. Bloques de recuperation. En esta aproximacion, cada componente del programa in- 
cluye una prueba para verificar que el componente se ha ejecutado con exito. Tam- 
bien incluye codigo alternativo que permite que el sistema vuelva hacia atras y re- 
pita los calculos si la prueba detecta un fallo de ejecucion. De forma deliberada, las 
implementaciones son interpretaciones diferentes de la misma especificacion. Se 
ejecutan en secuencia en lugar de en paralelo, de forma que no se requiere la repli- 
cacion de hardware. En la programacion con «-versiones, las implementaciones 
pueden serdistintas, pero no es infrecuente para dos o mas equipos de desarrollo ele- 
gir los mismos algoritmos para implementar la especificacion. Randell (Randell. 
1975) y Randell y Xu (Randell y Xu, 1995) describen el metodo de bloques de re- 
cuperacion. 

La provision de tolerancia a defectos del software requiere que el software sea ejecutado 
bajo el control de un controlador tolerante a defectos que asegure que se ejecuten los pasos 
relacionados con la tolerancia a defectos. Este controlador examina las salidas y las compa- 
re. Si difieren, se inician algunas acciones de recuperacion. Laprie y otros (Laprie etal., 1995) 
describen las arquitecturas de los sistemas tolerantes a defectos. 

Ambas aproximaciones a ia tolerancia a defectos hacen uso de la diversidad de diseno e 
implementacion. Cuando se utilizan varias aproximaciones para implementar la misma espe- 
cificacion, es una suposicion razonable que las diferentes versiones del software no incluyan 
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los mismos defectos, por lo que los fallos comunes son poco probables. La diversidad se pue- 
de lograr de diferentes formas: 

1 . Incluyendo requerimientos que deberian usarse bajo diferentes aproximaciones de di - 
sefio. Por ejemplo, un equipo puede producirun diseflo orientado a objetosy otro equi- 
po puede producir un diseflo orientado a funciones. 

2. Exigiendo que las implementaciones fuesen escritas en diferentes lenguajes de pro- 
gramacion. Por ejemplo, enun sistemacon tres versiones, se podrian usar Ada, C++ 
y Java para escribir las versiones del software. 

3. Exigiendo el uso de diferentes herramientas y entornos de desarrollo para el sistema. 

4. Exigiendo de forma explicita diferentes algoritmos a utilizar en algunas partes de la 
implementacion. Sin embargo, esto limita la libertad del equipo de diseflo y puede ser 
dificil de reconciliarcon los requerimientos de rendimiento del sistema. 

Cada equipo de desarrollo deberia trabajar con una especificacion del sistema — la espe- 
cificacion V — que ha sido derivada de la especificacion de los requerimientos del sistema 
(Avizienis, 1995). Asi como se especifica la funcionalidad del sistema, la especificacion V de- 
beria definirdonde se generan las comparaciones para las salidas del sistema. Los equipos de 
desarrollo para cada version deberian trabajar de forma independiente para reducir la proba- 
bilidad de desarrollar malentendidos comunes sobre el sistema. 

La diversidad del diseflo ciertamente incrementa la fiabilidad total del sistema. Sin em- 
bargo, varios experimentos han sugerido que la suposicion de que los equipos independien- 
tes de desarrollo no cometen los mismos errores no siempre es valida (Knight y Leveson, 
1986; Brilliant el ah, 1990; Leveson, 1995). Los equipos de desarrollo pueden cometer los 
mismos errores debido a malas interpretaciones comunes de la especificacion o debido a que 
de forma independiente llegan a los mismos algoritmos para resolver el problema. Los blo- 
ques de recuperacion reducen la probabilidad de errores comunes debido a que se utilizan di- 
ferentes algoritmos de forma explicita para cada bloque de recuperacion. 

Las desventajas de ambas aproximaciones a la tolerancia a fallos es que estan basadas en la 
suposicion de que la especificacion es correcta. Estas no toleran errores en la especificacion. En 
muchos casos, sin embargo, la especificacion es incorrecta o incompleta, por lo que el sistema 
se comporta de forma inesperada. Una forma de reducir la posibilidad de errores comunes en la 
especificacion es desarrollar las especificaciones V para el sistema de forma independiente y de- 
finir las especificaciones en distintos lenguajes. Un equipo de desarrollo podria trabajar a partir 
de una especificacion formal, otro a partir de un modelo del sistema basado en estados, y el ter- 
cero a partir de una especificacion en lenguaje natural. Esto ayuda a evitar algunos errores de la 
interpretacion de las especificaciones, perono evitael problema de errores en la especificacion. 
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PUNTOS CLAVE 

• La confiabilidad en un programa se puede conseguir evitando la introduccion de defectos, detectando y e I i - 
minando defectos antes del despliegue del sistema e incluyendo facilidades de tolerancia a defectos que per* 
miten que el sistema permanezca en funcionamiento despues de que un defecto ha provocado un f alio de eje- 
cucion del sistema. 
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• El uso de redundancia y diversidad tanto en los procesos software como en los sistemas software es esencial 
para el desarrollo de sistemas confiables. 

• El uso de un proceso repeti ble y bien definido es importante si se tienen que minimizar los defectos en un sls- 
tema. El proceso deberia incluir actividades deverificacionyvalidacidnen todas las eta pas, desde la defini- 
cion de los requerimientos hasta la implementation del sistema. 

• Algunas tec ni easy const rucciones deprogramacion, tales como sentencias goto, punteros, recursion, heren- 
ciaynumerosencoma flotante, sonintnnsecamentepropensasa errores. Estas no deberia n utilizarse cuan- 
do se desarrollan sistemas confiables. 

Los cuatro aspectosde la programacion de la tolerancia a defectos son deteccion de fallos de ejecucion. eva- 
luacion de los danos, recuperacion de defectos y reparacion de defectos. 

• La programacion con n-versiones y bloques de recuperacion son aproximaciones alternativas a las arquitec- 
turas tolerantes a defectos en las que se mantienen copias redundantes del hardware y software. Ambas cuen- 
tan con la diversidad del diseno y el uso de un controlador tolerante a defectos para coordinar ta ejecucion de 
tas unidades de programas redundantes. 



lecturas adi ci on ales Blk. r v WBVEMLI^VIVK^& 

Software Fault Tolerance Techniques and Implementation, Una descripcion facil de entender de tecnicas para con- 
seguir software tolerante a defectos y arquitecturas tolerantes a defectos. El libro tambien trata cuestiones gene- 
rales de confiabilidad del software. (L. L Pullum, 2001, Artech House.) 

Handbook of Software Reliability Engineering. Esta coleccion incluye varios articulos que describen los bloques de 
recuperacion y la programacion con n-versiones. Tambien incluye un buen articulo sobre arquitecturas de sistemas 
tolerantes a defectos. [M. R. Lyu (ed.), 1996, McGraw-Hill.] 



EJERCICIOS 

20.1 De cuatro razones de por que casi nunca es rentable para las empresas asegurar que su software esta li- 
bre de defectos. 

20.2 De dos ejemplos de diversidad y actividades redundantes que podrian incorporarse en procesos confia- 
bles. 

20.3 Explique por que la herencia es una construccion potencialmente propensa a errores y por que su uso de- 
beria minimizarse cuando se desarrollan sistemas criticos en un lenguaje orientado a objetos. 

204 Comente los problemas de desarrollar y mantener sistemas «siempre activos» tales como el software para 
una central telefonica. ^Como podrian utilizarse las excepciones en el desarrollo de tales sistemas? 

20.5 Explique por que deberia manejar de forma explicita todas las excepciones en un sistema tolerante a de- 
fectos. 
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20.6 Describa brevemente las estrategias de recuperacion de defectos hacia adelante y hacia atras. ^Por que 
se usa mas frecuentemente la recuperacion de defectos hacia atras que hacia adelante? De dos ejemplos 
de clases de sistemas en losque se podria utilizar la recuperacion de errores hacia atras. 

20.7 iQue es esencial para que la recuperacion de errores hacia adelante pueda tmplementarse en un sistema 
tolerante a defectos? ^Es posible la recuperacion de errores hacia adelante en sistemas interactivos? 

20.8 Disene un tipo abstracto de datos o clase de objetos denominado RobustList que imptemente la recupe- 
racion de errores hacia adelante en una lista enlazada. Usted deberia incluiroperaciones para comprobar 
los dafios en ta lista y reconstruir la lista si ocurre algun dano. Suponga que puede comprobar los dafios 
manteniendo referencias hacia adelante y hacia atras desde y hasta miembros adyacentes de la lista. 

20.9 Sugiera circunstancias en las que sea apropiado utilizar arquitecturas tolerantes a defectos cuando se im- 
plements un sistema de control basado en software y explique porque se requiere esta aproximacion. 

20.10 Se ha sugerido que el software de control para una maquina de terapia de radiaciones (utilizada para tra- 
tara pacientes con cancer) deberia implementarse utilizando n-versiones. Comente si piensa que esta es 
una buena sugerencia. 

20.11 De dos razones de por que las versiones de los sistemas en un sistema con n-versiones pueden fallar de 
forma similar. 

20.12 El uso de las tecnicas descritas aqui para producir software seguro obviamente implica costes adicionales 
considerables. ^Que costes adicionales pueden justificarse si too vidas pudiesen salvarse durante 15 anos 
de la vida de un sistema? ^Podrian justificarse los mismos costes si se salvasen 10 vidas? ^Cual es el va- 
lor de una vida humana? ^La capacidad adquisitiva de la gente implicada hace que haya alguna diferencia 
en este juicio de valor? 
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Objetivos 

El objetivo de este capitulo es introducir la evolucion del software 
para describir varias formas de modificar el software. Cuando haya 
leido este capitulo: 

• comprendera que el cambio es inevitable si los sistemas 
software tienen que seguir siendo utiles y que el desarrollo del 
software y la evolucion del software pueden integrarse en un 
modelo en espiral; 

• habra aprendido sobre diferentes tipos de mantenimiento del 
software y los factores que afectan a los costes de 
mantenimiento; 

• sera consciente de los procesos implicados en la evolucion del 
software, incluido el proceso de la reingenieria del software; 

• comprendera como los sistemas heredados pueden ser 
evaluados para decidir si deberian ser desechados, 
mantenidos, redesarrollados o reemplazados. 

Contenidos 

21.1 Dinamica de evolucion de los programas 

21.2 Mantenimiento del software 

21.3 Procesos de evolucion 

21.4 Evolucion de sistemas heredados 
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Despues de que los sistemas hayan sido desarrollados, inevitablemente han de sufrir cambios 
si tienen que seguir siendo utiles. Una vez que el software comienza a utilizarse, surgen nue- 
vos requerimientos y los requerimientos existentes cambian. Los cambios en los negocios a 
menudo generan nuevos requerimientos para el software existente. Algunas partes del soft- 
ware tienen que modificarse para corregir errores encontrados en su funcionamiento, adap- 
tarlo a una nueva plataforma y mejorar su rendimiento u otras caracteristicas no funcionales. 
El desarrollo del software, por lo tanto, no se detiene cuando un sistema es entregado, sino 
que continua durante el tiempo de vida del sistema. 

La evolucion del software es importante debido a que las organizaciones actualmente son 
completamente dependientes de sus sistemas software y han invertido millones de dolares en 
ellos. Los sistemas software son activos de negocio criticos y las organizaciones deben invertir 
en los cambios del sistema para mantener el valor de estos activos. Por lo tanto, en grandes 
compafiias, la mayorparte del presupuesto de software se dedica a mantener los sistemas exis- 
tentes, y no deberia sorprender que algunas figuras como las de Erlikh (Erlikh, 2000) sugie- 
ran que el 90% de los costes del software sean costes de evolucion. Sin embargo, hay bastante 
incertidumbre en este porcentaje, ya que la gente quiere decir diferentes cosas cuando se re- 
fiere a la evolucion o a los costes de mantenimiento. 

Como se indica mas adelante, los cambios posteriores al desarrollo no estan relacionados 
simplemente con la reparacion de defectos del software. La mayoriade los cambios son una 
consecuencia de que se generan nuevos requerimientos como respuesta a cambios en el ne- 
gocio y en las necesidades de los usuarios. Como consecuencia, se puede pensar en la inge- 
nicriadcl software como un proccso en cspiral con requerimientos, discno, implcmcntacion 
y pruebas que se realizan continuamente durante el tiempo de vida del sistema. Esto se ilus- 
tra en la Figura 21.1. Se comienza creando una Entrega 1 del sistema. Una vez entregada, los 
cambios propuestos y el desarrollo de la Entrega 2 comienzan casi inmediatamente. De he- 
cho, la necesidad de evolucion puede resultar obvia incluso antes de que se despliegue el sis- 
tema, de forma que posteriores entregas del software pueden estar en desarrollo antes de que 
la version inicial haya sido entregada. 

Este es un modelo idealizado de la evolucion del software que puede aplicarse en situa- 
ciones en las que una unica organizacion es responsable tanto del desarrollo inicial del soft- 
ware como de la evolucion del software. La mayoria de los productos software genericos se 
desarrollan utilizando esta aproximacion. Sin embargo, el software a medida puede desarro- 
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liarse externamente, pero la evolucion puede ser responsabilidad del personal de desarrollo 
del software del cliente. De forma alternativa, el usuario del software podria firmar un con- 
trato distinto con una compafna externa para el soporte y la evolucion del sistema. 

En este caso, se producen a menudo discontinuidades en el proceso en espiral. Los docu- 
mentos de requerimientos y diseno pueden no pasarse de una compaflia a otra. Las compa- 
nias pueden combinar o reorganizar y heredar software de otras compafiias, y entonces darse 
cuenta de que este tiene que cambiarse. Cuando la transicion desde el desarrollo a la evolu- 
cion no es continua, el proceso de cambiar el software despues de su entrega se denomina a 
menudo mantenimiento del software. Tal y como se expone mas adelante en este capitulo, el 
mantenimiento implicaactividades adicionales del proceso, como lacomprension del progra- 
ma, ademas de las actividades normales del desarrollo del software. 

21.1 Dinamica de evolucion de los programas 

La dinamica de evolucion de los programas es el estudio de los cambios del sistema. La ma- 
yor parte del trabajo en esta area ha sido realizada por Lehman y Belady, primero en los 
anos 70 y tambien en los 80 {Lehman y Belady, 1985). El trabajo continuo en los 90 cuan- 
do Lehman y otros investigaron la importancia de la realimentacion en los procesos de evo- 
lucion (Lehman, 1996; Lehman et al., 1998; Lehman et al., 2001). A partir de estos estu- 
dios, propusieron un conjunto de leyes (las leyes de Lehman) concernientes a los cambios 
de los sistemas. Senalan que estas leyes (hipotesis, realmente) son invariantes y amplia- 
mente aplicables. Lehman y Belady examinaron el crecimiento y la evolucion de varios sis- 
temas software grandes. Las leyes propuestas, mostradas en la Figura 21.2, se derivaron de 
estas medidas. 





Cambio continuado 


Un programa que se usa en un entomo real necesariamente debe cambiar o se vorvera 
progresrvamente menos util en ese entomo. 


Complejidad creciente 


A medida que un programa en evolucion cambia, su estructura tiende a ser cada vez mas 
compleja. Se deben dedfcar recursos extras para preservar y simplificar la estructura. 


Evotuci6n prolongada del programs 


La evo!uci6n de los programas es un proceso autorregulativo. Los atributos de los siste- 
mas, tales como tamafto, tiempo entre entrega s y el numero de errores documentados, 
son aproximadamente invariantes para cada entrega del sistema. 


Estabilidad organizational 


Durante el tiempo de vida de un programa, su velocidad de desarrollo es aproximada- 
mente constante e independiente de los recursos dedicados al desarrollo del sistema. 


Conservaci6n de la familiaridad 


Durante el tiempo de vida de un sistema, el cambio incremental en cada entrega es apro- 
ximadamente constante. 


Crecimiento continuado 


La funcionalidad ofrecida por bs sistemas tiene que crecer continuamente para mante- 
ner la satisfaccidn de los usuarios. 


Decremento de la caiidad 


La caiidad de los sistemas comenzara' a disminuir a menos que dkhos sistemas se adap- 
ten a los cambios en su entomo de fundonamiento. 


Realimentacion del sistema 


Los procesos de evolucion incorporan sistemas de realimentacion muttiagente y murrj- 
bude y estos deben ser tratados como sistemas de realimentacion para lograr una me- 
jora stgnifkativa del producto. 

Figura 21.2 Leyes de Lehman. 
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La primera ley establece que el mantenimiento de los sistemas es un proceso inevita- 
ble. A medida que el entorno del sistema cambia, surgen nuevos requerimientos y el sis- 
tema debe ser modificado. Cuando el sistema modificado vuelve a introducirse en el en- 
torno, este promueve mas cambios en el entorno, de forma que el proceso de evolucion se 
recicla. 

La segunda ley establece que, a medida que se cambia un sistema, su estructura se degra- 
da. La unica forma de evitar este hecho, es invertir en mantenimiento preventivo en el que se 
consume tiempo mejorando la estructura del software sin aiiadir funcionalidades. Obviamen- 
te, esto implica costes adicionales, ademas de aquellos derivados de la implementacion de los 
cambios requeridos del sistema. 

La tercera ley es, quizas, la mas interesante y discutida de las leyes de Lehman. Sugiere 
que los grandes sistemas tienen su propia dinamica que se establece en una etapa temprana 
en el proceso de desarrollo. Esta determina las tendencias generales del proceso de manteni- 
miento del sistema y limita el numero de posibles cambios en el sistema. 

Lehman y Belady sugieren que esta ley es una consecuencia de factores estructurales que 
influencian y restringen los cambios de los sistemas, asi como de factores organizacionales 
que afectan al proceso de evolucion. 

Una vez que un sistema excede algun tamano minimo, se vuelve mas dificil de cambiar. 
Debido a que es mas grande y mas complejo, el sistema es mas dificil de entender, y es mas 
probable que los programadores cometan errores e introduzcan defectos en el sistema. Por lo 
tanto, la realizacion de pequenos cambios evita reducir la confiabilidad del sistema. Un gran 
cambio introducira probablemente muchos defectos nuevos que limitaran el cambio util en- 
tregado en la nueva version del sistema. 

Los grandes sistemas son producidos normalmente por grandes organizaciones, que tie- 
nen una burocracia interna que fija el presupuesto para el cambio de cada sistema y con- 
trola el proceso de toma de decisiones. Las organizaciones tienen que tomar decisiones so- 
bre los riesgos y el valor de los cambios y los costes implicados. Tales decisiones llevan su 
tiempo. Durante ese tiempo, se pueden proponer otros cambios del sistema con mayor prio- 
ridad. Puede ser necesario retrasar los cambios originales hasta una fecha posterior. Por lo 
tanto, los procesos de toma de decisiones de la organizacion gobiernan la velocidad del 
cambio del sistema. 

La cuarta ley de Lehman sugiere que la mayoria de los proyectos de programacion gran- 
des trabajan en lo que se denomina un estado saturado. Es decir, un cambio en los recursos o 
en el personal tiene efectos imperceptibles en la evolucion a largo plazo del sistema. Esto con- 
cuerda con la tercera ley, que sugiere que la evolucion del programa es independiente en gran 
medida de las decisiones de gestion. Esta ley confirma que los grandes grupos de desarrollo 
software son a menudo improductivos debido a que las sobrecargas en las comunicaciones do- 
minan el trabajo del grupo. 

La quinta ley de Lehman se refiere a los incrementos de los cambios en cada entrega del 
sistema. Anadir nueva funcionalidad a un sistema inevitablemente introduce nuevos defectos 
en el sistema. Cuanta mas funcionalidad se anada en cada entrega, mas defectos habra. Por lo 
tanto, un incremento grande de funcionalidad en una entrega del sistema significa que tendra 
que ir seguida de una entrega adicional en la que se reparen los nuevos defectos del sistema. 
Relativamente pocas nuevas funcionalidades se incluiran en esta entrega. La ley sugiere que 
no deberian presupuestarse incrementos grandes de funcionalidad en cada entrega sin tener 
en cuenta la necesidad de reparacion de defectos. 

Las cinco primeras leyes fueron las propuestas iniciales de Lehman; las restantes leyes fue- 
ron anadidas despues de posteriores trabajos. Las leyes sextay septima son similares y dicen 
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esencialmente que los usuarios del software estaran cada vez mas descontentos con dicho soft- 
ware a menos que este se mantenga y se le afiadan nuevas funcionalidades. La ultima ley re- 
fleja el trabajo mas reciente sobre procesos de realimentacion, si bien todavia no esta claro 
como puede aplicarse en el desarrollo practico del software. 

Las observaciones de Lehman parecen razonables por lo general. Deberian tenerse en 
cuenta cuando se planifica el proceso de mantenimiento. Puede ser que las consideraciones 
del negocio requieran prescindir de ellas en algun momento. Por ejemplo, por razones co- 
merciales, puede ser necesario realizar cambios mayores en el sistema en una unica entrega. 
Las consecuencias probables de esto son que se requieran una o mas entregas dedicadas a la 
reparacion de los errores introducidos. 

Puede parecer que las diferencias radicales que son obvias entre entregas de productos de 
programas violan las leyes de Lehman. Por ejemplo, Microsoft Word se transformo desde un 
sencillo procesadorde textos que funcionaba con 256 K de memoria a un gigantesco sistema 
con multitud de caracteristicas. Actualmente necesita muchos megabytes de memoria y un 
procesador rapido para que funcione, Su evolucion parece contradecir las leyes de Lehman 
cuarta y quinta. Sin embargo, se presume que este programa no es realmente una secuencia 
de revisiones a partir de un programa nucleo comun. Mas bien, el nombre se ha conservado 
por razones comerciales, pero el programa en si mismo ha sido reescrito y reestructurado mas 
de una vez desde que fue entregado originalmente. 

21.2 Mantenimiento del software 

El mantenimiento del software es el proceso general de cambiar un sistema despues de que 
este ha sido entregado. El termino se aplica normalmente a software a medida en donde gru- 
pos de desarrollo distintos estan implicados antes y despues de la entrega. Los cambios rea- 
lizados al software pueden ser cambios sencillos para corregir errores de codigo, cambios mas 
extensos para corregir errores de diseno o mejoras significativas para corregir errores de es- 
pecificacion o acomodar nuevos requerimientos. Los cambios se implementan modificando 
los componentes del sistema existente y anadiendo nuevos componentes al sistema donde sea 
necesario. 

Existen tres tipos diferentes de mantenimiento de software: 

1 . Mantenimiento para reparar defectos de! software. Por lo general, los errores de co- 
digo son relativamente baratos de corregir; los errores de diseno son mucho mas ca- 
ros ya que implican reescribir varios componentes de los programas. Los errores de 
requerimientos son los mas caros de reparar debido a que puede ser necesario un re- 
diseno extenso del sistema. 

2. Mantenimiento para adaptar el software a diferentes entornos operativos. Este tipo de 
mantenimiento se requiere cuando cambia algun aspecto del entorno del sistema, 

como por ejemplo el hardware, la plataforma del sistema operativo u otro software de 
soporte. El sistema de aplicaciones debe modificarse para adaptarse a estos cambios 
en el entorno. 

3 . Mantenimiento para ahadir o modificar las funcionalidades del sistema. Este tipo de 
mantenimiento es necesario cuando los requerimientos del sistema cambian como 
respuesta a cambios organizacionales o del negocio. La escala de los cambios reque- 
ridos en el software es a menudo mucho mayor que en los otros tipos de manteni- 
miento. 
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En la practica, no existe una clara distincion entre estos tipos de mantenimiento. Cuando 
se adapta el sistema a un nuevo entorno, pueden anadirse funcionalidades para aprovechar las 
ventajas de las nuevas caracteristicas del entorno. Los defectos del software a menudo se 
muestran debido a que los usuarios utilizan el sistema en formas no anticipadas. La mejor for- 
ma de reparar estos defectos consiste en realizar cambios en el sistema que se adapten a su 
forma de trabajo. 

Normalmente se reconocen estos tipos de mantenimiento, pero varias personas les dan dis- 
tintos nombres. El mantenimiento correctivo se utiliza generalmente para referirse al mante- 
nimiento para reparacion de defectos. Sin embargo, el mantenimiento adaptativo algunas ve- 
ces significa adaptarse a un nuevo entorno y puede significar adaptar el software a nuevos 
requerimientos. El mantenimiento perfectivo puede significar perfeccionar el software im- 
plementando nuevos requerimientos; en otros casos significa mantener la funcionalidad del 
sistema, pero mejorando su estructura y su rendimiento. Debido a esta incertidumbre en los 
nombres, se ha evitado usar todos estos terminos en este capitulo. 

Los trabajos de Lientz y Swanson (Lientz y Swanson, 1980) y los de Nosek y Palvia (No- 
sek y Palvia, 1990) sugieren que alrededor del 65% del mantenimiento esta relacionado con 
la implementacion de nuevos requerimientos, el 18% con cambios en el sistema para adap- 
tarlo a un nuevo entorno operativo y el 17% para corregir defectos en el sistema (Figura 21.3). 
Para sistemas a medida, la distribucion de estos costes todavia es aproximadamente correcta. 
La cuestion importante no es la de los porcentajes especificos, sino el hecho de que la repa- 
racion de defectos en los sistemas no es la actividad de mantenimiento mas cara. La evolu- 
cion del sistema para adaptarse a nuevos entornos y requerimientos nuevos o cambios en los 
mismos consume la mayor parte del esfuerzo de mantenimiento. 

Los costes de mantenimiento constituyen una proporcion de los costes de desarrollo y va- 
rian de un dominio de aplicacion a otro. Guimaraes (Guimaraes, 1983) sugiere que los costes 
de mantenimiento para sistemas de aplicaciones corporativas son en general comparables con 
los costes de desarrollo de los sistemas. Para sistemas de tiempo real embebidos, los costes 
de mantenimiento pueden serhasta cuatro veces mayores que los costes de desarrollo. Los re- 
querimientos de alta fiabilidad y rendimiento de estos sistemas a menudo implican que los 
modulos tienen que estar estrechamente enlazados y, por lo tanto, seran dificiles de cambiar. 

Normalmente resulta rentable invertir esfuerzo eneldisefio e implementaciondeun siste- 
ma para reducir los costes de mantenimiento. Anadir nuevas funcionalidades despues de la en- 
trega es caro debido a que hay que emplear tiempo en la compresion del sistema y en el ana- 
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lisis del impacto de los cambios propuestos. Por lo tanto, el trabajo realizado durante el des- 
arrollo para hacerque el software sea mas facil de entendery de cambiar, probablemente re- 
duzca los costes de mantenimiento. Buenas tecnicas de ingenieria del software tales como una 
especificacion precisa, el uso de desarrollo orientado a objetos y gestion de configuraciones 
contribuyen a la reduccion de los costes de mantenimiento. 

La Figura 21.4 muestra como los costes totales del tiempo de vida pueden decrecer cuan- 
to mas esfuerzo se emplee durante el desarrollo del sistema para producir un sistema mante- 
nible. Debido a la reduccion potencial en los costes de comprension, analisisy pruebas, exis- 
te un efecto multiplicador significativo cuando el sistema se desarrolla pensando en la 
mantenibilidad. Para el Sistema 1, se invierten unos costes de desarrollo extras de 25.000 do - 
lares para hacerque el sistema sea mas mantenible. Esto se convierte en un ahorro de 100.000 
dolares en los costes de mantenimiento durante la vida del sistema, lo que supone un incre- 
mento del porcentaje en los costes de desarrollo que conduce a un porcentaje decreciente com- 
parable en los costes totales del sistema. 

Una razon importante de por que los costes de mantenimiento son altos es que es mas caro 
afiadir funcionalidades despues de que el sistema este en funcionamiento que implementar la 
misma funcionalidad durante el desarrollo. Los factores clave que distinguen el desarrollo y 
el mantenimiento, y que conducen a costes de mantenimiento mas elevados, son: 

1. Estabilidad del equipo. Despues de entregar un sistema, es normal que el equipo de 
desarrollo de disuelva y la gente trabaje en nuevos proyectos. El nuevo equipo o los 
individuos responsables del mantenimiento del sistema no comprenden dicho sistema 
o las razones de fondo de las decisiones de su diseno. Se dedica demasiado esfuerzo 
durante el proceso de mantenimiento en comprender el sistema antes de implementar 
cambios sobre el. 

2. Responsabilidad contractual. El contrato para mantener un sistema normalmente esta 
separado del contrato para desarrollar el sistema. El contrato de mantenimiento pue- 
de darse con una compania diferente en lugarde con el desarrollador original del sis- 
tema. Este factor, junto con la ausencia de estabilidad del equipo, implica que no exis- 
te incentivo para que un equipo de desarrollo escriba el software para que sea facil de 
cambiar. Si el equipo de desarrollo realiza ciertas acciones para ahorrar esfuerzo du- 
rante el desarrollo, lo hara sin preocuparse demasiado aunque esto signifique incre- 
mentar los costes de mantenimiento. 

3. Habilidades del personal. El personal de mantenimiento a menudo no tiene experien- 
cia y no esta familiarizado con el dominio de la aplicacion. El mantenimiento tiene una 
pobre imagen entre los ingenieros software. Esta visto como un proceso que requiere 
menos habilidades que el desarrollo del sistema y a menudo se asigna al personal prin- 
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ripiante. Ademas, los sistemas antiguos pueden haberse escrito en lenguajes de pro- 
gramacion obsoletos. El personal de mantenimiento puede no tener mucha experien- 
cia de desarrollo en estos lenguajes y debe aprenderlos para mantener el sistema. 
4. Edady estructura del programa. A medida que pasa el tiempo, la estructura de los pro- 
gramas tiende a degradarse con los cambios, por lo que se vuelve mas dificil de com- 
prender y modificar. Algunos sistemas han sido desarrollados sin tecnicas modernas 
de ingenieria del software. Pueden no haber sido nunca bien estructurados y quiza es- 
ten optimizados para su eficiencia en lugar de para su comprensibilidad. La docu- 
mentacion del sistema puede haberse perdido o ser inconsistente. Los sistemas anti- 
guos pueden no haber sido sometidos a gestion de configuraciones, por lo que a 
menudo se emplea mucho tiempo en encontrar las versiones correctas de los compo- 
nentes del sistema a cambiar. 

Los tres primeros problemas surgen del hecho de que muchas organizaciones todavia con- 
sideran el desarrollo y el mantenimiento como actividades independientes. El mantenimien- 
to se ve como una actividad de segunda categoria, y no es un incentivo emplear mas dinero 
durante el desarrollo para reducir los costes de los cambios en el sistema. La unica solucion 
a largo plazo a este problema es aceptar que los sistemas raramente tienen un tiempo de vida 
definido, pero continuaran en uso, de alguna forma, durante unperiodo de tiempo indefinido. 
Tal y como se sugirio en la introduccion, deberiapensarse que los sistemas evolucionan du- 
rante su ciclo de vida a traves de un proceso de desarrollo continuado. 

El cuarto problema, el de la degradacion de la estructura del sistema, es en cierto modo el 
mas facil de solucionar. Las tecnicas de reingenieria del software (brevemente descritas mas 
adelante en este capitulo) pueden aplicarse para mejorar la estructura del sistema y su com- 
prensibilidad. Las transformaciones arquitectonicas pueden adaptar el sistema a un nuevo 
hardware. El trabajo de mantenimiento preventivo (esencialmente la reingenieria incremen- 
tal) puede soportarse para mejorar el sistema y hacer que sea mas facil de cambiar. 

21.2.1 Pre dice ion del mantenimiento 

Los gestores odian las sorpresas, especialmente si estas conducen a costes elevados inespera- 
dos. Por lo tanto, se deberia intentar predecir que cambios del sistema son probables y que 
partes del sistema son probablemente las mas dificiles de mantener. Tambien se deberia in- 
tentar estimar los costes totales de mantenimiento para un sistema durante un periodo de tiem- 
po determinado. LaFigura21.5 ilustra estas predicciones y cuestiones asociadas. Comoes ob- 
vio, estas predicciones estan estrechamente relacionadas: 

1 . La aceptacion o no de un cambio en el sistema depende, hasta cierto punto, de la man- 
tenibilidad de los componentes del sistema afectados por dicho cambio. 

2. La implementacion de los cambios del sistema tiende a degradar la estructura de di- 
cho sistema y, por lo tanto, reduce su mantenibilidad. 

3. Los costes de mantenimiento dependen del numero de cambios, y los costes de la im- 
plementacion de los cambios dependen de la mantenibilidad de los componentes del 
sistema. 

La prediccion del numero de peticiones de cambios para un sistema requiere entender la 
relacion entre el sistema y su entorno. Algunos sistemas tienen una relacion muy compleja 
con su enlomo y los cambios en ese entorno inevitablemente provocan cambios en el siste- 
ma. Para evaluar las relaciones entre un sistema y su entorno, deberia tenerse en cuenta: 



21.2 • Mantenimiento del software 45 5 



iQue partes del sistema 
son mis probables de 

afectarse por las 
peticiones de cambio? 




cQue partes del sistema 
seran mas costosas 
de mantenef? 



iCuiles serin los costes 
de mantenimiento durante 
el periodo de vida 
del sistema? 



tCuantas peticiones 
de cambio se esperan? 



iCuales serin los costes 
de mantenimiento de este 
sistema en el proximo afio? 



Figura 21.5 Prediccion del mantenimiento. 

1. El numero y la complejidad de las interfaces del sistema. Cuanto mayor sea el nume- 
ro de interfaces y mas complejas sean estas, es mas probable que se hagan mas peti- 
ciones de cambio. 

2. El numero de requerimientos del sistema intrinsecamente voldtiles. Tal y como indi- 
ca en el Capitulo 7, los requerimientos que reflejan politicas y procedimientos orga- 
nizacionales son probablemente mas volatiles que los requerimientos que se basan en 
caracteristicas estables del dominio. 

3. Losprocesos de negocios en ios quese utiliza el sistema. Puesto que los procesos de 
negocios evolucionan, generan peticiones de cambio del sistema. Cuanto mas proce- 
sos de negocios utilice el sistema, habra mas peticiones de cambio del sistema. 

Para predecir la mantenibilidad del sistema, es necesario comprender el numero y los ti- 
pos de relaciones entre los componentes del sistema. Se han realizado varios estudios sobre 
los diferentes tipos de complejidad en un sistema (McCabe, 1976; Halstead, 1977) y sobre las 
relaciones entre la complejidad y la mantenibilidad (Kafura y Reddy, 1987; Banker et ah. 
1993). No es sorprendente que estos estudios senalaran que cuanto mas complejo es un com- 
ponente o sistema, mas caro es de mantener. 

Las medidas de la complejidad han resultado ser particularmente utiles para identificar 
componentes individuales de programas que probablemente sean especialmente caros de 
mantener. Kafura y Reddy (Kafura y Reddy. 1987) examinaron varios componentes de siste- 
mas y comprobaron que el esfuerzo de mantenimiento tendia a centrarse en un pequefio nu- 
mero de componentes complejos. Sugirieron que, para reducir los costes de mantenimiento, 
se deberian reemplazar componentes del sistema particularmente complejos con alternativas 
mas sencillas. 

Despues de que el sistema se haya puesto en funcionamiento, se pueden usar los datos del 
proceso para ayudar a predecir la mantenibilidad. Ejemplos de metricas del proceso que pue- 
den utilizarse para evaluar la mantenibilidad son: 

1. El numero de peticiones de mantenimiento correctivo. Un crecimiento en el numero 
de informes de fallos de ejecucion puede indicar que se han introducido mas errores 



456 CAPITULO 21 • Evolucion del software 



en el programa de los que se han corregido durante el proceso de mantenimiento. Esto 
puede suponeruna disminucion de la mantenibilidad. 

2 . El tiempo medio requerido para el analisis de impacto. Este refleja el numero de com- 
ponentes del programa que se ven afectados por una peticion de cambio. Si este tiem- 
po se incrementa, implica que mas y mas componentes se ven afectados y que la man- 
tenibilidad disminuye. 

3 . El tiempo medio empleado en implementar una peticion de cambio. Este no es el mis- 
mo que el tiempo para el analisis de impacto, aunque esta relacionado con et. Se tra- 
ta de la cantidad de tiempo que se necesita para modificar realmente el sistema y su 
documentacion, despues de que hayaevaluado que componentes seven afectados. Un 
incremento en el tiempo necesario para implementar un cambio puede indicar una dis- 
minucion en la mantenibilidad. 

4. El numero de peticiones de cambio pendientes. Un incremento en este numero a lo lar- 
go del tiempo puede implicar una disminucion en la mantenibilidad. 

Para predecir los costes de mantenimiento se utiliza la informacion de predicciones so- 
bre peticiones de cambio y sobre la mantenibilidad del sistema. La mayoria de los gesto- 
res combinan esta informacion con intuicion y experiencia para estimar los costes. El mo- 
delo COCOM02de estimacion de costes (Boehm et a/., 2000), descrito en el Capitulo 
26, sugiere que una estimacion del esfuerzo de mantenimiento del software puede basar- 
se en el esfuerzo de comprender el codigo existente y el esfuerzo de desarrollar nuevo co- 
digo. 

21.3 Procesos de evolucion 

Los procesos de evolucion del software varian considerablemente dependiendo del tipo de 
software a mantener, los procesos de desarrollo utilizados en una organizacion y el personal 
implicado en el proceso. En algunas organizaciones, la evolucion puede ser un proceso in- 
formal en el que la mayor parte de las peticiones de cambios surgen de conversaciones entre 
los usuarios del sistema y los desarrolladores. En otras companias, hay un proceso formali- 
zado en el que se produce documentacion estructurada en cada etapa del proceso. 

Las propuestas de cambios del sistema son los conductores de la evolucion de los sistemas 
en todas las organizaciones. Estas propuestas de cambio pueden ser requerimientos existen- 
tes que no han sido implementados en el sistema entregado, peticiones para nuevos requeri- 
mientos y reparaciones de errores por parte de los stakeholders del sistema, y nuevas ideas y 
propuestas para mejoras en el software por parte del equipo de desarrollo del sistema. Tal y 
como se ilustra en la Figura 21.6, los procesos de identificacion de cambios y evolucion del 
sistema son ciclicos y continuan durante toda la vida del sistema. 

Los procesos de evolucion incluyen las actividades fundamentales de analisis de cam- 
bios, planificacion de entregas, implementacion del sistema y entrega de un sistema a los 
clientes. Se evalua el coste e impacto de estos cambios para ver en que medida se ve afec- 
tado el sistema por el cambio y cuanto cuesta implementar el cambio. Si los cambios pro- 
puestas son aceptados, se planifica una nueva entrega del sistema. Durante la planificacion 
de entregas, se consideran todos los cambios propuestas (reparacion de defectos, adapta- 
cion y nuevas funcionalidades). A continuacion, se decide con que lenguajes se va a im- 
plementar la siguiente version del sistema. Se implementan y validan los cambios, y se en- 
trega una nueva version del sistema. El proceso entonces itera con un nuevo conjunto de 
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cambios propuestos para la siguiente entrega. La Figura 21.7, adaptada de Arthur (Arthur, 
1988), muestra un esquema de este proceso. 

El proceso de implementacion de los cambios es, esencialmente, una iteracion del proce- 
so de desarrollo en la que se disenan, implementan y praeban las revisiones del sistema. Sin 
embargo, una diferencia fundamental es que la etapa inicial de la implementacion de los cam- 
bios es la comprension del programa. Durante esta fase, se tiene que entender como esta es- 
tructurado el programa y como realiza su funcionalidad. Cuando se implementa un cambio, 
se usa este entendimiento para estar seguro de que el cambio implementado no afecta de for- 
ma adversa al sistema existente. 

Idealmente, la etapa de implementacion de los cambios de este proceso deberia modificar 
laespecificaciondel sistema, disenoe implementacion para reflejar los cambios del sistema 
(Figura 21.8). Se proponen, analizan y validan nuevos requerimientos que reflejan los cam- 
bios del sistema. Los componentes del sistema son redisenados e implementados y el sistema 
se vuelve a probar. Si es conveniente, pueden realizarse prototipos de los cambios propuestos 
como parte del proceso de analisis de los cambios. 

A medida que se cambia el software, se desarrollan entregas sucesivas del sistema. Estas 
estan compuestas a partir de versiones de los componentes del sistema. Tiene que hacerse un 
seguimiento de estas versiones para asegurarse de que se utilizan las versiones correctas de 
los componentes en cada entrega del sistema. La gestion de configuraciones se trata en el Ca- 
pitulo 29. 
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Durante los procesos de evolucion, los requerimientos se analizan con detalle y frecuente- 
mente surgen las implicaciones de los cambios que no eran evidentes en la etapa mas temprana 
del proceso de analisis de los cambios. Esto significa que los cambios propuestos pueden mo- 
dificarse y pueden requerirse discusiones adicionales con el cliente antes de que sean imple- 
mentados. 

Algunas veces, las peticiones de cambio estan relacionadas con problemas en el sistema 
que tienen que solucionarse de manera muy urgente. Estos cambios urgentes pueden tener lu- 
gar por tres razones: 

1 . SI ocurre un defecto serio en el sistema que tenga que ser reparado para permitir la 
continuacion del funcionamiento normal. 

2. Si los cambios en el entorno del sistema operativo tienen efectos inesperados que im- 
piden el funcionamiento normal. 

3. Si hay cambios no anticipados en las empresas que utilizan el sistema, tales como la 
aparicion de nuevos competidores o la introduccion de una nueva legislacion. 

En estos casos, la necesidad de realizar el cambio rapidamente significa que usted puede 
resultar imposible seguirel proceso de analisis formal del cambio. En lugarde modificar los 
requerimientos y diseno, se realiza una reparacion de emergencia en el programa para resol- 
ver el problema inmediato (Figura 21.9). Sin embargo, el peligro esta en que los requeri- 
mientos, el diseno del software y el codigo gradualmente se vuelven inconsistentes. Mientras 
se intenta documentar los cambios en los requerimientos y el diseno, pueden ser necesarias 
reparaciones de emergencia adicionales. Estas tienen prioridad sobre la documentacion. Fi- 
nalmente, el cambio original se olvida y la documentacion del sistema y el codigo nunca vuel- 
ven a ser consistentes. 

Un problema adicional con las reparaciones de emergencia del sistema es que tienen que 
completarse lo mas rapidamente posible. Se elige una solucion funcional rapida en lugarde 
la mejor solucion que concierne a la estructura del sistema. Esto acelera el proceso del enve- 
jecimiento del software de forma que futuros cambios son progresivamente mas dificiles y los 
costes de mantenimiento se incrementan. 

Idealmente, cuando se realizan reparaciones de codigo de emergencia, la peticion de cam- 
bio deberia seguir existiendo despues de que los defectos hayan sido corregidos. Entonces esta 
puede ser reimplementada mas cuidadosamente despues de un posterior analisis. Por supues- 
to, puede reutilizarse el codigo de la reparacion. Otra solucion mejor al problema puede des- 
cubrirse cuando se tiene mas tiempo para realizar el analisis. Sin embargo, en la practica, es 
casi siempre inevitable que estos cambios tengan una prioridad baja y, despues de que se ha- 
yan hecho cambios adicionales en el sistema, no es realista volver a hacer las reparaciones de 
emergencia. 
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21.3.1 Reingenieria de slstemas 

Tal y como se indica en la seccion anterior, el proceso de evolucion de los sistemas implica 
comprender el programa que tiene que cambiarse, y a continuacion implementar estos cam- 
bios. Sin embargo, muchos sistemas, especialmente los sistemas heredados mas antiguos 
(descritos en el Capitulo 2) son dificiles de comprender y de cambiar. Los programas pueden 
haber sido optimizados originalmente para su rendimiento o utilizacion de la memoria a ex- 
pensas de su comprensibilidad o, a lo largo del tiempo, la estructura inicial del programa pue- 
de haberse corrompido por una serie de cambios. 

Para simplificar los problemas de cambiar sus sistemas heredados, una compafna puede de- 
cidir hacer reingenieria sobre esos sistemas para mejorar su estructura y comprensibilidad. La 
reingenieria del software se refiere a la reimplementacion de los sistemas heredados para ha- 
cerlos mas mantenibles. La reingenieria puede implicar redocumentar el sistema, organizary 
reestructurar el sistema, traducir el sistema a un lenguaje de programacion mas moderno, y mo- 
dificar y actualizar la estructura y valores de los datos del sistema. La funcionalidad del soft- 
ware no se cambia y, normalmente, la arquitectura del sistema tambien sigue siendo la misma. 

Hacer reingenieria de un sistema software tiene dos ventajas clave sobre aproximaciones 
mas radicales a la evolucion del sistema: 

1. Riesgo reducldo. Existe un alto riesgo en volver a desarrollar software critico para los 
negocios. Pueden cometerse errores en la especificacion, o puede haber problemas en 
el desarrollo. Los retrasos en la introduccion del nuevo software pueden significarper- 
didas en el negocio e incurrir en costes adicionales. Por ejemplo, en 1999 una gran 
compania de comida en Estados Unidos tuvo retrasos en la introduccion de un nuevo 
sistema de pedidos, lo que condujo a retrasos en las entregas de productos valoradas 
en 100 millones de dolares en una estacion de maxima venta. 

2. Coste reducido. E 1 coste de hacer reingenieria es significativamente menor que el cos- 
te de desarrollar nuevo software. Ulrich (Ulrich, 1990) cita un ejemplo de un sistema 
comercial en el que los costes de reimplementacion se estimaron en 50 millones de do - 
lares. Al sistema se le aplico reingenieria con exito por 1 2 millones de dolares . Se pre- 
sume que, con la tecnologia moderna del software, el coste relativo de la reimple- 
mentacion probablemente sea menor, pero aun asi supera de forma considerable los 
costes de la reingenieria. 

La distincion critica entre reingenieria y nuevo desarrollo software es el punto de partida 
del desarrollo. En lugar de empezar con una especificacion escrita, el sistema antiguo actua 
como una especificacion para el nuevo sistema, Chikofskyy Cross (Chikofskyy Cross, 1990) 
denominan al desarrollo convencional ingenieria hacia adelante para distinguirla de la rein- 
genieria del software. Esta distincion se muestraen la Figura 21.10. La ingenieria hacia ade- 
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lante comienza con una especificacion del sistema e implica el diseno e implementacion de 
un nuevo sistema. La reingenieria comienza con un sistema existente y el proceso de desa- 
rrollo para su reemplazo se basa en comprendery transformar el sistema original. 

La Figura 21.11 ilustrael proceso de reingenieria. La entrada del proceso es un programa 
heredado y la salida es una version modularizada y estructurada del mismo programa. Durante 
la reingenieria del programa, los datos del sistema tambien sufren reingenieria. Las activida- 
des de este proceso de reingenieria son: 

1. Traduction del codigofuente. El programa es convertido desde un lenguaje de pro- 
gramacion antiguo a una version mas moderna del mismo lenguaje o a un lenguaje di- 
ferente. 

2. Ingenieria inversa. El programa se analizay se extrae informacion apartirde el. Esto 
ayuda a documentar su organizacion y funcionalidad. 

3 . Mejora de ;a estructura de los programas. La estructura de control del programa se 
analiza y modifica para hacerla mas facil de leery comprender. 

4. Modularization de los programas. Se agrupan las partes relacionadas del programa y 
se elimina la redundancia en donde resulta adecuado. En algunos casos, esta etapa pue- 
de implicar una transformacion arquitectonica en la que un sistema centralizado pen- 
sado para una unica computadora se modifica para ejecutarse sobre una plataforma 
distribuida. 

5. Reingenieria de datos. Los datos procesados por el programa se cambian para refle- 
jar los cambios en el. 

La reingenieria del sistema no requiere necesariamente todos los pasos de la Figura 21.11. 
La traduccion de codigo fuente puede no ser necesaria si el lenguaje de programacion utilizado 
para desarrollar el sistema todavia esta soportado por el suministrador del compilador. Si la rein- 
genieria se realiza completamente con herramientas automaticas, entonces recuperar la docu- 
mentacion mediante ingenieria inversa puede no ser necesario. La reingenieria de datos solo se 
requiere si las estructuras de datos del programa cambian durante la reingenieria del sistema. Sin 
embargo, la reingenieria del software siempre implica alguna reconstruccion del programa. Para 
hacer que el sistema que ha sufrido reingenieria interopere con el nuevo software, tienen que 
desarrollarse adaptadores de componentes, como se explico en el Capitulo 19. Este oculta las 
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Figura 21.11 El proceso de reingenieria. 
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interfaces originales del sistema software y presenta nuevas interfaces mejor estructuradas que 
pueden ser utilizadas por otros componentes. El proceso de envolver este sistema heredado es 
una tecnica importante para desarrollar componentes reutilizables a gran escala. 

Los costes de la reingenieria obviamente dependen de la magnitud del trabajo que tiene que 
llevarse a cabo, tal y como muestra la Figura 21.12. Los costes se incrementan desde la iz- 
quierda hacia la derecha para que la traduccionde codigo fuente sea laopcion mas economi- 
ca. La reingenieria, como parte de una migracion arquitectonica, es la opcion mas cara. 

Ademas de la amplitud de la reingenieria, los principales factores que afectan a los costes 
de reingenieria son: 

1. La calldad del software sobre el quese va a hacer reingenieria. Cuanto masbaja sea 
la calidad del software y su documentacion asociada (si la hay), mas altos seran los 
costes de reingenieria. 

2. Las herramientas de soporte disponibles para la reingenieria. Normalmente no es ren- 
table hacer reingenieria sobre un sistema software a menos que puedan utilizarse he- 
rramientas CASE para automatizar la mayor parte de los cambios en los programas. 

3. La amplitud de la conversion de datos requerida. Si el sistema sobre el que se va a ha- 
cer reingenieria requiere que se conviertan grandes volumenes de datos, el coste del 
proceso se incrementa de forma significativa. 

4. La disponibilidad de personal experto. Si el personal responsable de mantener el sis- 
tema no puede implicarse en el proceso de reingenieria, los costes se incrementaran 
debido a que los ingenieros encargados de la reingenieria tienen que invertiruna gran 
cantidad de tiempo en comprender el sistema. 

La principal desventajade la reingenieria del software esqueexistenlimitespracticosala 
extension del sistema que puede ser mejorada mediante reingenieria. No esposible,porejem- 
plo, convertir un sistema disenado utilizando una aproximacion funcional en un sistema orien- 
tado a objetos. Los cambios arquitectonicos mayores o la reorganizacion radical de la gestion 
de datos del sistema no pueden realizarse de forma automatica, por lo que se incurrira en cos- 
tes adicionales elevados. Aunque la reingenieria puede mejorar la mantenibilidad, el sistema 
al que se va a aplicar reingenieria probablemente no sera tan mantenible como un nuevo sis- 
tema desarrollado utilizando metodos modernos de ingenieria del software. 



21.4 Evolucion de sistemas heredados 



Para los sistemas software nuevos desarrollados utilizando procesos de ingenieria del soft- 
ware modernos tales como desarrollo iterativo y CB SE, es posible planificar como integrar 
el desarrollo del sistema y la evolucion. Mas y mas companias han empezado a comprender 



462 CAPITULO 21 • Evoluci on del software 



que el proceso de desarrollo de los sistemas es un proceso del ciclo de vida en su totalidad y 
que una separacion artificial entre el desarrollo del software y su mantenimiento no resulta 
util. Sin embargo, existen todavia muchos sistemas heredados que son sistemas de negocio 
criticos. Estos tienen que extenderse y adaptarse para las practicas cambiantes de comercio 
electronico. 

Las organizaciones que cuentan con un presupuesto limitado para mantener y actualizar sus 
sistemas heredados tienen que decidir como obtener los mejores beneficios a su inversion. 
Esto significa que tienen que realizar evaluaciones realistas de sus sistemas heredados y a con- 
tinuacion decidir cual es la estrategiamas adecuadapara la evolucion de estos sistemas. Exis- 
ten cuatro opciones estrategicas : 

1. Desechar completamente el sistema. Esta opcion deberia elegirse cuando el sistema 
no constituye una contribucion efectiva para los procesos de negocio. Esto ocurre 
cuando los procesos de negocio han cambiado desde que se instalo el sistema y ya no 
son completamente dependientes de este. Esta situacion es mas comun cuando las ter- 
minales mainframe fueron reemplazadas porPCs, y el software comercial sobre estas 
maquinas fue adaptado para proporcionar la mayor parte del soporte que el proceso de 
negocio necesita. 

2 . Dejar el sistema sin cambiosy continuar con un mantenimiento regular. Esta op- 
cion deberia elegirse cuando el sistema todavia es necesario pero es muy estable y 
los usuarios del sistema solicitan un numero relativamente pequeno de peticiones de 
cambio. 

3. Hacer reingenieria del sistema para mejorarsu mantenibilidad. Esta opcion deberia 
elegirse cuando la calidad del sistema se ha degradado por los cambios continuos y 
cuando dichos cambios todavia son necesarios. Tal y como se ha indicado, este pro- 
ceso puede incluir el desarrollo de nuevos componentes de interfaz para que el siste- 
ma original pueda trabajar con otros sistemas mas nuevos. 

4. Reemplazar todo o parte del sistema con un nuevo sistema. Esta opcion deberia ele- 
girse cuando otros factores, como un nuevo hardware, implican que el sistema antiguo 
no puede continuar en funcionamiento o cuando los sistemas comerciales deberian 
permitir desarrollar el nuevo sistema con un coste razonable. En muchos casos puede 
adoptarse una estrategia de reemplazo evolutiva en la que los mayores componentes 
del sistema son reemplazados por sistemas comerciales con otros componentes reuti- 
lizados siempre que sea posible. 

Naturalmente, estas opciones no son exclusivas, por lo que, cuando un sistema se corn- 
pone de varios programas, pueden aplicarse diferentes opciones a distintas partes del sis- 
tema. 

Cuando se esta evaluando un sistema heredado, este tiene que verse desde una perspecti- 
va de negocio y desde una perspectiva tecnica (Warren. 1998). Desde una perspectiva de ne- 
gocio, tiene que decidirse si el negocio realmente necesita del sistema. Desde una perspecti- 
va tecnica, tiene que evaluarse la calidad de la aplicacion software y del software y hardware 
de soporte del sistema. A continuacion, debe utilizarse una combinacion del valor del nego- 
cio y de la calidad del sistema para informar de lo que se ha decidido hacer con el sistema he- 
redado. 

Para ilustrar esto, supongamos que una organizacion tiene diez sistemas heredados. El va- 
lor del negocio y de la calidad de cada uno de estos sistemas se evalua y se compara con otros 
creando un grafico que muestra el valor relativo del negocio y de la calidad del sistema. Esto 
se ilustra en la Figura 21.13. 
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A partirde la Figura 21.13, puede verse que existen cuatro clases de sistemas: 

1. Baja calidad y bajo valor de negocio. Mantener estos sistemas en funcionamiento sera 
caro y la tasa de beneficios para el negocio sera bastante pequefta. Estos sistemas de- 
berian desecharse. 

2. Baja calidad y alto valor de negocio. Estos sistemas constituyen una importante con- 
tribucion al negocio, por lo que no pueden desecharse. Sin embargo, su baja calidad 
significa que son caros de mantener. A estos sistemas deberia aplicarseles reingenie- 
ria para mejorar su calidad o deberian ser reemplazados, si esta disponible un sistema 
comercial adecuado. 

3. Alta calidad y bajo valor de negocio. Estos son sistemas que no contribuyen mucho 
al negocio, pero que no son muy caros de mantener. No vale la pena reemplazar estos 
sistemas para que su mantenimiento normal pueda continuar durante mas tiempo, ya 
que no se requieren cambios caros y el hardware del sistema es operacional. Si es ne- 
cesario realizar cambios caros, estos deberian desecharse. 

4. Alta calidad y alto valor de negocio. Estos sistemas tienen que seguir manteniendo su 
funcionamiento, pero su elevada calidad significa que no se tiene que invertir en su 
transformacion o reemplazo de los sistemas. El mantenimiento normal de los sistemas 
deberia continuar. 

Para evaluar el valor de negocio de un sistema, se tiene que identificar a los stakeholders 
del sistema, tales como usuarios finales del sistema y sus gestores, y plantearles una serie 
de cuestiones sobre dicho sistema. Existen cuatro cuestiones basicas que deberian abor- 
darse: 

1. El uso del sistema. Si los sistemas solo se utilizan de forma ocasional por un pequeflo 
numero de personas, pueden tenerunbajo valor de negocio. Un sistema heredado pue- 
de haber sido desarrollado para satisfacer una necesidad de negocio que o bien ha cam- 
biado o no puede satisfacerse de manera efectiva de otras formas. 

2. Los procesos de negocio que estdn soportados. Cuando se introduce un sistema, pue- 
den disenarse procesos de negocio para explotar ese sistema. Sin embargo, cambiares- 
tos procesos puede resultar imposible debido a que el sistema heredado no puede ser 
adaptado. Por lo tanto, un sistema puede tener un bajo valor de negocio debido a que 
no pueden introducirse nuevos procesos. 
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3. Contabilidad del sistema. La confiabilidad del sistema no solo es un problema tecnico sino 
tambien un problema de negocio. Si un sistema no es confiable y los problemas afectan di- 
rectamente a los clientes del negocio o suponen que las personas del negocio son aparta- 
das de otras tareas para resolver estos problemas, el sistema tiene un bajo valor de negocio. 

4. Salidas del sistema. La clave fundamental aqui es la importancia de las salidas del sis- 
tema para un funcionamiento con exito del negocio. Si el negocio depende de estas sa- 
lidas, entonces el sistema tiene un alto valor de negocio. A la inversa, si estas salidas 
pueden generarse facilmente de alguna otra forma o si el sistema produce salidas que 
se usan raramente, entonces su valor de negocio puede ser bajo. 

Por ejemplo, supongamos que una compania proporciona un sistema de pedidos de viajes en 
que el personal responsable de organizar el viaje puede emitir ordenes con un agente de viajes 
concertado. A continuacion, se entregan los billetes y se pasan las facturas a la compania. Sin 
embargo, una evaluacion del valor de negocio puede revelar que este sistema solo es utilizado 
por un pequeiio porcentaje de peticiones de viaje emitidas. Las personas que organizan los via- 
jes pueden encontrar mas barato y mas conveniente tratar directamente con los proveedores de 
los viajes a traves de sus sitios web. Este sistema todavia puede utilizarse, pero no hay un mo- 
tivo real para mantenerlo. La misma funcionalidad esta disponible desde sistemas extemos. 

De forma inversa, supongamos que una compania ha desarrollado un sistema que realiza 
un seguimiento de todas las peticiones previas de los clientes, y automaticamente genera avi- 
sos a los clientes para volver a pedir los productos. Esto provoca un gran numero de pedidos 
repetidos y mantiene a los clientes satisfechos debido a que ellos sienten que su proveedor esta 
preocupado por sus necesidades. Las salidas de un sistema como este son muy importantes 
para el negocio; por lo tanto, el sistema tiene un alto valor de negocio. 

Para evaluar el software del sistema desde una perspectiva tecnica, se necesita considerar 
tanto la aplicacion del sistema en si misma, como el entorno en el cual opera. El entorno in- 
cluye el hardware y todo el software de soporte asociado, como compiladores y enlazadores, 
necesarios para mantener el sistema. El entorno es importante debido a que muchos cambios 
en el sistema se obtienen a partir de cambios en el entorno, como actualizaciones del hard- 
ware o del sistema operativo. 

En el proceso de evaluacion del entorno, si es posible, deberian hacerse mediciones del sis- 
tema y de sus procesos de mantenimiento. Ejemplos de datos que pueden ser utiles son los 
costes de mantener el hardware del sistema y el software de soporte, el numero de defectos 
hardware que se manifiestan durante algun periodo de tiempo y la frecuencia de las repara- 
ciones aplicadas al software de soporte del sistema. 

Los factores que deberian considerarse durante la evaluacion del entorno se muestran en 
laFigura21.14. Tengase en cuenta que estos factores no sontodos caracteristicas tecnicas del 
entorno; tambien tiene que considerar la fiabilidad de los proveedores del hardware y del sis- 
tema de soporte. Si estos proveedores ya no estan en el negocio, puede no haber soporte de 
mantenimiento para sus sistemas. 

Para evaluar la calidad tecnica de un sistema de aplicaciones, tiene que evaluarse una se- 
rie de rangos (Figura 21.15) que estan relacionados fundamentalmente con la confiabilidad 
del sistema, las dificultades de mantener el sistema y la documentacion del mismo. Tambien 
tienen que recogerse datos cuantitativos del sistema que ayuden ajuzgar su calidad. Ejemplos 
de datos cuantitativos que podrian obtenerse son: 

1. El numero de peticiones de cambio del sistema. Los cambios del sistema tienden a co- 
rromper la estructura del mismo y hacer que cambios adicionales sean mas dificiles. 
Cuanto mas alto sea este valor, mas baja sera la calidad del sistema. 
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biara por sistemas mas modemos. 


Rendimiento 


£Es adecuado el rendimiento del sistema? iTtenen los probfe- 
mas de rendimiento un efecto significative sobre los usuarios 
del sistema? 


Requerimientos de soporte 


£Que soporte local es requerido por el hardware y d software? 
Si existen costes elevados asodados con este soporte, puede 
merecer la pena considerar la sustjtudon del sistema. 



Costes de mantenimiento tCuales son los costes de mantenimiento del hardware y licen- 

das de software de soporte? Et hardware mas antiguo poede te- 
ner costes de mantenimiento mas elevados que tos sistemas 
modemos. El software de soporte tambien puede tener altos 
costes anuales de licenda. 



Interoperabilidad i Existen problemas derivados de la interfaz del sistema con 

otros sistemas? ilos compiladores pueden, por ejemplo, ubli- 
zarse con versiones actuates del sistema operative? iSe requie- 
re emuladon hardware? 



Figura 21.14 

Factores utilizados 
en la evaluacion 
del entorno. 



2. El numero de interfaces de usuarlo. Este es un factor importante en sistemas basados 
en formularios, en los que cada formulario puede considerarse como una interfaz de 
usuario independiente. Cuantas mas interfaces haya, es mas probable que haya incon- 
sistencias y redundancias en dichas interfaces. 

3. El volumen dedatos utilizados por el sistema. Cuanto mas alto sea el volumende 
datos (numero de ficheros, tamano de la base de datos, etc.), mas complejo sera el 
sistema. 

Aunque a menudo estos datos son utiles, el obtenerlos puede resultar muy caro y, por lo 
tanto, poco practico. Ademas, no existen valores absolutos que se puedan utilizar. La edad y 
el tamano del sistema tienen que tenerse en cuenta cuando se realizan juicios de calidad ba- 
sados en mediciones. 

Idealmente, la evaluacion objetiva deberia utilizarse para informar de las decisiones sobre 
lo que hay que hacer con un sistema heredado. Sin embargo, en muchos casos, estas decisio- 
nes no son realmente objetivas, sino que se basan en consideraciones politicas u organizacio- 
nales. Por ejemplo, si dos empresas se fusionan, la que sea mas poderosa politicamente por 
lo general mantendra sus sistemas y desechara el resto de los sistemas. Si los gestores senior 
de una organizacion deciden cambiar a una nueva plataforma hardware, entonces esto puede 
requerir el reemplazo de aplicaciones. Si no hay presupuesto disponible para la transforma- 
cion del sistema en un ano concreto, entonces el mantenimiento del sistema puede continuar 
incluso aunque esto de lugar a costes elevados a largo plazo. 
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Evolution del soiware 
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tantes? 
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<tdn 

- tMudfaadasend abtemaactuaf? 

IGdMen datas de pruebes para d interna? £Exbteunregislrode laspiiiefoasdefegresl6nlle> 
*4ei a cabo cuando ae hen aAadto nuevu caractertticas d staenie7 

Uaap*nona>dbponibi«ttiai^tashabikdadespara tr^^ 
ndntero Imnado de penonas que comprenda d srstema? 

iErlsten datas de pruebas para d ststema? ufaste un reglstro de las prueba 
wajas a cabo cuando sellanarlada 
^Uspcfsonasoopcrtblcs tlenen 

numero Imitado de personas que comprenda d slstema? 
Flgura 21.15 Factores utilizados en la evaluacion de la aplicacidn. 



PUNTOS CLAVE 

• B desanofto del software y su evoluclon debenan ser in unlco prooeso Rerabvo Hegado que pueda repre- 
seritBBB uHzando in modeto en espiral 

* las byes de Lehman, oomo la noclon de que el cantio es conbhuo, describen varias obsenadones a parbr 
de ssfcjutos a largo pbn> de b evoluclon de bs sistamasL 

* Bdsfeen lies Upos de hsntanriento det software; correction de entires, modlflcaclon del soflwEie para tra- 
bajar en in nuevo> entorno, e imptementacion de lequenrienbos nuevos o camfans en estos. 

* Para sbkmas a medda, bs cosfees de irWrkflMBnta del softnete gsnentannb BNOBfJen a bs costos de des- 
anrjpo del software: 

• B prooeso de ta evoluclon dd software esta oanduddo par peGcbnes de cambb e triune anallsls dd knpacto 
de bs carnbhs, planificacion de b enbeeja e implementacion de bs cambbs. 

• La reingenierfa del soflwate se ref lere a la reestructuracion y redocumentacion del software para haoerio mas 
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nan ser evaruados para d eteniiiar si el sistema dene que ser reemprazado, tragfannarJo o marttenMo. 
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LECTURAS ADICIONALES 

Modernizing Legacy Systems: Software Technologies, Engineering Processes, and Business Practices. Este exce- 
lente libro trata cuestiones generales del mantenimiento y evolucion del software asi como de la migracion de sis- 
temas heredados. El libro se basa en un gran caso de estudio de la transformacion de un sistema COBOL a un sis- 
tema cliente-servidor basado en Java. (R. C. Seacord et ai. 2003, Addison-Wesley.) 

The Renaissance of Legacy Systems. Este libro se refiere en su mayor parte a los metodos para hacer evolucionar los sis- 
temas heredados. Sin embargo, incluye unabuena exposicion general de estos sistemas, casos de estudio que ilustran 
las estructuras de los sistemas heredados y un capitulo sobre la evaluacion de sistemas. (I. Warren, 1998, Springer). 



E J E R C I C I 0 S 

2L1 Explique por que un sistema software que se usa en un entorno real debe cambiar o se volvera progresi- 
vamente menos util. 

2L2 Explique la razon de ser subyacente de las leyes de Lehman. ^En que circunstancias podrian no ser apli- 
cables estas leyes? 

2L3 Describa brevemente los tres tipos de mantenimiento del software. ^Por que es dificil a veces distinguir- 
los entre si? 

21.4 A usted, como gestor de proyectos software en una compania especializada en el desarrollo de software 
para la industria petrolera cerca de la costa, se le ha encomendado la tarea de descubrir los factores que 
afectan a la mantenibilidad de los sistemas desarrollados por su compania. Sugiera como podria estable- 
cer un programa para analizar el proceso de mantenimiento y descubrir metricas de mantenibilidad ade- 
cuadas para su compania. 

21.5 A partir de la Figura 21.7, usted puede ver que el analisis de impacto es un subproceso importante en el 
proceso de evolucion del software. Mediante un diagrama, sugiera que actividades deberian implicarse en 
el analisis del impacto de los cambios. 

21.6 ^Cuales son los principales factores que afectan a tos costes de reingenieria de los sistemas? 

21.7 ^Cuales son las condiciones esenciales para que la reingenieria del software tenga exito? 

2L8 Indique en que circunstancias podria una organizacion decidir desechar un sistema cuando la evaluacion 
de dicho sistema sugiere que tiene una alta calidad y un alto valor de negocio. 

21.9 ^Cuales son las opciones estrategicas para la evolucion de sistemas heredados? ^Cuando podria usted nor- 
malmente reemplazar todo o parte de un sistema en lugar de continuar manteniendo el software (con o 
sin reingenieria)? 

21.10 Explique por que los problemas con el software de soporte podrian implicar que una organizacion tenga 
que reemplazar sus sistemas heredados. 

21.11 ^Tienen los ingenieros software una responsabilidad profesional para producir codigo que este prepara- 
do para evolucionar incluso si esto no esta explicitamente solicitado por sus clientes? 

2L12 La gestion de una organizacion le ha pedido que lleve a cabo una evaluacion del sistema y le sugiere que 
le gustaria que los resultados de dicha evaluacion mostrasen que el sistema es obsoleto y que deberia ser 
reemplazado porun nuevo sistema. Esto significara que varios mantenedores del sistema perderan su tra- 
bajo. Su evaluacion realmente muestra que el sistema esta bien mantenido y que tiene una alta calidad y 
un alto valor de negocio. ^Como podria informarde estos resultados a la gestion de la organizacion? 



VERIFICACION 



Capftulo 22 Verification y validacion 
Capftulo 23 Pruebas del software 
Capftulo 24 Validacion de sistemas cn'ticos 



Pro bar u n programa es la forma mas comun de comprobarque satisface su especifica- 
cion y hace lo que el diente quiere que haga. Sin embargo, las pruebas solo son una de 
las tecnicas de verificacion y validacion. Algunas de estas tecnicas, tales como las Ins- 
pecciones de programas, han sido utilizadas durante casi treinta alios, pero todavia no 
se han convertido en tendencias principales de la ingenieria del software. 

En esta parte del libro, se tratan las aproximaciones para verificar que el software sa- 
tisface su especif Icaclon y validar que tambien satisface las necesidades del cliente del 
software. Esta parte del libro tiene tres capitulos relacionados con diferentes aspectos de 
la verificacion y validacion: 

1. El Capitulo 22 presenta una vision general de las aproximaciones para Ea verifica- 
cion y validacion. Se explica la distincion entre verificacion y validacion, y el pro- 
ceso de planif icacion de la V & V. A continuacion, se describen las tecnicas estati- 
cas para la verificacion de los sistemas. Estas son tecnicas en las que se 
comprueba el codigofuente del programa en lugarde probarsu ejecucion. Se es- 
tudian las inspecciones de programas, el uso de analisis estatico automatizado y, 
finalmente, el rol de los metodos formales en el proceso deverificacion. 

2. Lapruebade programas es el tema del Capitulo 23. Se explica como las pruebas 
se llevan a cabo normalmente en diferentes niveles y se muestran las diferencias 
entre pruebas de componentes y pruebas del sistema. Utilizando ejemplos sen- 
cillos, se introducen varias de las tecnicas que pueden utilizarse para disenar ca- 
sos de prueba para los programas y, por ultimo, se expone brevemente la auto- 
matizacion de las pruebas. La automa tizacion de las pruebas es el uso de 
herramientas software que ayudan a reducir el tiempo y el esfuerzo implicado en 
los procesos de pruebas. 

3. El Capftulo24t rata el tenia mas especializadodevalidacionde sistemas cnticos. 
Para los sistemas criticos, se tiene que probar a un cliente o a un regulador ex- 
tern oqueel sistema satisface suespecificaciony requerimientos de confiabilidad. 
Se describen las aproximaciones para la evaluacion de la habilidad, seguridad y 
proteccion, y se explica como se puede utilizar la evidencia en los procesos de V 
& V del sistema para el desarrollo de un caso de prueba de la confiabilidad del 
sistema. 



Verificacion 
validacion 



Objetivos 

El objetivo de este capitulo es introducir la verificacion y validacion 
del software con especial enfasis en las tecnicas de verificacion 
estatica. Cuando haya leido este capitulo: 

• comprendera las diferencias entre verificacion yvalidaciondel 
software; 

• habra sido introducido en las inspecciones de programas como 
un metodo para descubrir defectos en los programas; 

• comprendera que es el analisis estatico automatizado y como 
se utiliza en verificacion y validacion; 

• comprendera como se utiliza la verificacion estatica en el 
proceso de desarrollo de Sala Limpia. 

Contenidos 

22.1 Planificacion de la verificacion y validacion 

22.2 Inspecciones de software 

22.3 Analisis estatico automatizado 

22.4 Verificacion y metodos formales 
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Durante y despues del proceso de implementacion, el programa que se esta desarrollando debe 
ser comprobado para asegurar que satisface su especificacion y entrega la funcionalidad es- 
perada por las personas que pagan por el software. La verificacion y la validacion (V & V) es 
el nombre dado a estos procesos de analisis y pruebas. La verificacion y la validacion tienen 
lugar en cada etapa del proceso del software. V & V comienza con revisiones de los requeri- 
mientos y continiia con revisiones del diseno e inspecciones de codigo hasta la prueba del pro- 
ducto. 

La verificacion y la validacion no son lo mismo, aunque a menudo se confunden. Boehm 
(Boehm, 1979) expreso de forma sucinta la diferencia entre ellas: 

• «Validaci6n: ^Estamos construyendo el producto correcto?» 

• «Verificaci6n: ^Estamos construyendo el producto correctamente?» 

Estas definiciones nos dicenque el papel de la verificacion implica comprobarque el soft- 
ware esta de acuerdo con su especificacion. Deberia comprobarse que satisface sus requeri- 
mientos funcionales y no funcionales. La validacion, sin embargo, es un proceso mas gene- 
ral. El objetivo de la validacion es asegurar que el sistema software satisface las expectativas 
del cliente. Va mas alia de la comprobacion de que el sistema satisface su especificacion para 
demostrar que el software hace lo que el cliente espera que haga. Tal y como se expone en la 
Parte 2, las especificaciones del sistema software no siempre reflejan los deseos o necesida- 
des reales de los usuarios y los propietarios del sistema. 

El objetivo ultimo del proceso de verificacion y validacion es establecer la seguridad de 
que el sistema software esta «hecho para un proposito». Esto significaque el sistema debe ser 
lo suficientemente bueno para su uso pretendido. El nivel de confianza requerido depende del 
proposito del sistema, las expectativas de los usuarios del sistema y el entorno de mercado ac- 
tual del sistema: 

1. Funcion del software. El nivel de confianza requerido depende de lo critico que sea el 
software para una organizacion. Por ejemplo, el nivel de confianza requerido para el 
software que se utiliza para controlar un sistema de seguridad critico es mucho mas 
alto que el requerido para un prototipo de un sistema software que ha sido desarrolla- 
do para demostrar algunas ideas nuevas. 

2. Expectativas del usuario. Una reflexion lamentable sobre la industria del software 
es que muchos usuarios tienen pocas expectativas sobre su software y no se sor- 
prenden cuando este falla durante su uso. Estan dispuestos a aceptar estos fallos del 
sistema cuando los beneficios de su uso son mayores que sus desventajas. Sin em- 
bargo, la tolerancia de los usuarios a los fallos de los sistemas esta decreciendo des- 
de los anos 90. Actualmente es menos aceptable entregar sistemas no fiables, por 
lo que las compafiias de software deben invertir mas esfuerzo para verificar y vali- 
dar. 

3. Entorno de mercado. Cuando un sistema se comercializa, los vendedores del sistema 
deben tener en cuenta los programas competidores, el precio que sus clientes estan dis- 
puestos a pagar por el sistema y la agenda requerida para entregar dicho sistema. 
Cuando una compania tiene pocos competidores, puede decidir entregar un programa 
antes de que haya sido completamente probado y depurado, debido a que quiere ser el 
primero en el mercado. Cuando los clientes no estan dispuestos a pagar precios altos 
por el software, pueden estar dispuestos a tolerar mas defectos en el. Todos estos fac- 
tores pueden considerarse cuando se decide cuanto esfuerzo deberia invertirse en el 
proceso de V & V. 
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Dentro del proceso de V & V, existen dos aproximaciones complementarias para el anali- 
sis y comprobacion de los sistemas: 

1 . Las inspecciones de software analizan y comprueban las representaciones del sistema 
tales como el documento de requerimientos, los diagramas de diseno y el codigo fuen- 
te del programa. Puede usarse las inspecciones en todas las etapas del proceso. Las ins- 
pecciones pueden ser complementadas con algun tipo de analisis automatico del co- 
digo fuente de un sistema o de los documentos asociados. Las inspecciones de 
software y los analisis automaticos son tecnicas de V & V estaticas, ya que no se ne- 
cesita ejecutar el software en una computadora. 

2. Laspruebas del software implican ejecutar una implementaciondel software con da- 
tes de prueba. Se examinan las salidas del software y su entorno operacional para com- 
probar que funciona tal y como se requiere. Las pruebas son una tecnica dinamica de 
verificacion y validacion. 

La Figura 22.1 muestra que las inspecciones del software y las pruebas son actividades 
complementarias en el proceso del software. Las flechas indican las etapas en el proceso en 
las que pueden utilizarse dichas tecnicas. Por lo tanto, se pueden utilizar las inspecciones del 
software en todas las etapas del proceso de desarrollo. Comenzando por los requerimientos, 
puede inspeccionarse cualquierrepresentacion legible del software. Tal y como se ha indica- 
do, las revisiones de los requerimientos y del diseno son las principales tecnicas utilizadas 
para la deteccion de errores en el diseno y la especificacion. 

Solo puede probarse un sistema cuando esta disponible un prototipo o una version ejecu- 
table del programa. Una ventaja del desarrollo incremental es que una version probable del 
sistema esta disponible en etapas tempranas del proceso de desarrollo. Las funcionalidades 
pueden probarse a medida que se van anadiendo al sistema, por lo que no tiene que realizar- 
se una implementacion completa antes de que comiencen las pruebas. 

Las tecnicas de inspeccion comprenden las inspecciones de programas, el analisis auto- 
matico del codigo fuente y la verificacion formal. Sin embargo, las tecnicas estaticas solo pue- 
den comprobar la correspondencia entre un programa y su especificacion (verificacion); no 
pueden demostrar que el software es operacionalmente util. Tampoco se pueden utilizar tec- 
nicas estaticas para comprobar las propiedades emergentes del software tales como su rendi- 
miento y fiabilidad. 

Aunque el uso de las inspecciones del software no es generalizado, la prueba de progra- 
mas siempre sera laprincipal tecnica de verificacion y validacion. Laspruebas implican eje- 
cutar el programa utilizando datos similares a los datos reales procesados por el programa. Los 



Figura 22.1 
Verificacion y 
validacion estatica y 
dinamica. 
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defectos en los programas se descubren examinando las salidas del programa y buscando las 
anomalias. Existen dos tipos distintos de pruebas que pueden utilizarse en diferentes etapas 
del proceso del software: 

1. Laspruebas de validation intentan demostrar que el software es el que el cliente quie- 
re — que satisface sus requerimientos — . Como parte de la prueba de validacion, se 
pueden utilizar pruebas estadisticas para probar el rendimiento y la fiabilidad de los 
programas, y para comprobar como trabaja en ciertas condiciones operacionales. En 
el Capitulo 24 se analizan las pruebas estadisticas y la estimacion de la fiabilidad. 

2. Laspruebas de defectos intentan revelar defectos en el sistema en lugar de simular su 
uso operacional. El objetivo de las pruebas de defectos es hallar inconsistencias entre 
un programa y su especificacion. En el Capitulo 23 se tratan las pruebas de defectos. 

Por supuesto, no existe un limite perfectamente definido entre estas aproximaciones de 
pruebas. Durante las pruebas de validacion, se encontraran defectos en el sistema. Durante 
las pruebas de defectos, alguno de los tests mostrara que el programa satisface sus requeri- 
mientos. 

Normalmente, los procesos de V & V y depuracion se intercalan. A medida que se descu- 
bren defectos en el programa que se esta probando, tiene que cambiarse este para corregir ta- 
les defectos. Sin embargo, las pruebas (o mas generalmente la verificacion y validacion) y la 
depuracion tienen diferentes objetivos: 

1 . Los procesos de verificacion y validacion intentan establecer la existencia de defectos 
en el sistema software. 

2. La depuracion es un proceso (Figura 22.2) que localiza y corrige estos defectos. 

No existe un metodo sencillo para la depuracion de programas. Los depuradores habilido- 
sos buscan patrones en las salidas de las pruebas en donde se ponen de manifiesto los defec- 
tos y utilizan su conocimiento sobre el tipo de defecto, el patron de salida, el lenguaje de pro- 
gramacion y el proceso de programacion para localizar el defecto. Durante el proceso de 
depuracion, puede utilizarse el conocimiento de errores comunes de programacion (como ol- 
vidar incrementar un contador) y hacer corresponder estos con los patrones observados. Tam- 
bien deberianbuscarse errores caracteristicos de los lenguajes de programacion, tales como 
errores de direccionamiento de punteros en C. 

Localizar los defectos en un programa no siempre es un proceso sencillo, ya que el defec- 
to puede no estar cerca del punto en el que fallo el programa. Para localizar un defecto de un 
programa, se puede tenerque disenar pruebas adicionales que reproduzcan el defecto origi- 
nal y que determinen con precision su localizacion en el programa. Se puede tener que hacer 
manualmente una traza del programa, linea por linea. Las herramientas de depuracion que re- 
copilan informacion sobre la ejecucion del programa tambien pueden ayudar a localizar la 
fuente de un problema. 



Resultados 
de pruebas 



Figura 22.2 
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Las herramientas de depuracion interactivas generalmente forman parte de un conjunto de 
herramientas de soporte del lenguaje que se integran con un sistema de compilacion. Estas 
proporcionan un entorno de ejecucion especializado para el programa que permite acceder a 
la tablade simbolosdel compiladory, desde aqui, a los valoresde las variables del programa. 
Se puede controlar la ejecucion «paso a paso» del programa sentenciapor sentencia. Despues 
de ejecutar cada sentencia, pueden examinar los valores de las variables y asi se puede des- 
cubrir la localizaciondel defecto. 

Cuando se ha descubierto un defecto en el programa, hay que corregirlo y volver a validar 
el sistema. Esto puede implicar volver a inspeccionar el programa o hacer pruebas de regre- 
sion en las que se ejecutan de nuevo los tests existentes. Las pruebas de regresion se utilizan 
para comprobar que los cambios en el programa no introducen nuevos defectos. La expe- 
riencia ha demostrado que una alta proporcion de «reparaciones» de defectos son incomple- 
tas o bien introducen nuevos defectos en el programa. 

En principio, deberian repetirse todos los tests despues de la reparacion de cada defecto. 
En la practica, esto normalmente supone un coste demasiado elevado. Como parte del plan de 
pruebas, deberian identificarse dependencias entre los componentes y las pruebas asociadas 
con cada componente. Esto es, deberia poderse establecer una traza entre los casos de prue- 
ba y los componentes que son probados. Si esta trazabilidad se documenta, entonces se pue- 
de ejecutar un subconjunto de los casos de prueba del sistema para comprobar el componen- 
te modificado y sus dependientes. 



22.1 Planificacion de la verificacion y validacion 

La verificacion y validacion es un proceso caro. Para algunos sistemas, tales como los siste- 
mas de tiempo real con restricciones no funcionales complejas, mas de la mitad del presu- 
puesto para el desarrollo del sistema puede invertirse en V & V. Es necesaria una planifica- 
cion cuidadosa para obtener el maximo provecho de las inspecciones y pruebas y controlar 
los costes del proceso de verificacion y validacion. 

Deberia comenzarse la planificacion de la verificacion y validacion del sistema en etapas 
tempranas del proceso de desarrollo. El modelo de proceso de desarrollo del software mos- 
trado en la Figura 22.3 se denomina a veces modelo V (girese la Figura 22.3 desde su extre- 
mo de la derecha para ver laV). Esuna instanciacion del modelo generico en cascada (vease 
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Figura 22.3 Planes de pruebas como un enlace entre las pruebas y el desarrollo. 
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el Capitulo 4) y muestra que los planes de pruebas deberian derivarse a partir de la especifi- 
cacion y diseno del sistema. Este modelo tambien divide la V & V del sistemaen varias eta- 
pas. Cada etapa esta conducida por las pruebas que tienen que definirse para comprobar la 
conformidad del programa con su diseno y especificacion. 

Como parte del proceso de planificacion de V & V, habria que decidir un equilibrio entre 
las aproximaciones estaticas y dinamicas de la verificacion y validacion, y pensar en estan- 
dares y procedimientos para las inspecciones y pruebas del software, establecer listas de com- 
probacion para conducir las inspecciones de programas (vease la Seccion 22.3) y definir el 
plan de pruebas del software. 

El relativo esfuerzo destinado a las inspecciones y las pruebas depende del tipo de sistema 
adesarrollary de los expertos de la organizacion en la inspeccion de programas. Como regla 
general, cuanto mas critico sea el sistema, deberia dedicarse mas esfuerzo a las tecnicas de 
verificacion estaticas. 

La planificacion de las pruebas esta relacionada con el establecimiento de estandares para 
el proceso de las pruebas, no solo con la descripcion de los productos de las pruebas. Los pla- 
nes de pruebas, ademas de ayudar a los gestores a asignar recursos y estimar el calendario de 
las pruebas, son de utilidad para los ingenieros del software implicados en el diseno y la rea- 
lizacion de las pruebas del sistema. Estos ayudan al personal tecnico a obtener una panora- 
mica general de las pruebas del sistema y ubicar su propio trabajo en este contexto. Una bue- 
na descripcion de los planes de pruebas y su relacion con los planes de calidad mas generales 
se proporciona en Frewin y Hatton (Frewin y Hatton, 1986). Humphrey (Humphrey, 1989) y 
Kit (Kit, 1995) tambien incluyen estudios sobre la planificacion de las pruebas. 

Los principales componentes de un plan de pruebas para un sistema grande y complejo 
se muestran en la Figura 22.4. Ademas de determinar el calendario y procedimientos de las 
pruebas, el plan de pruebas define los recursos hardware y software que se requieren. Este 
es util para los gestores del sistema que son los responsables de asegurar que estos recur- 

B pwcaso tfa piUGbd 

Una descripcion de lasprinapajesfases del proceso de prueba. Estas podrian describirse como se 
hizo anteriormente en este capitulo. 

■aaiVHoad da laquennams 

Los usuarios son los mas interesados en que el sistema satisfaga sus requerimientos y las prue- 
bas deberian planificarse pare que todos los requerimientos se prueben individualmente. 

Bementos probados 

Deberian especificarse los elementos del proceso del software que tienen que ser probados. 

Calendario da pniebas 

Un calendario de todas las pruebas y la asignacion de recursos para este calendario se enlaza, ob- 
viamente, con la agenda general del desarrollo del proyecto. 

PtooedMentos da raglsba de las pniebas 

No es suficiente ejecutar simplemente las pruebas; los resultados de las pruebas deben ser regis- 
trados sistematicamente. Debe ser posible auditar el proceso de pruebas para comprobar que se 
ha llevado a cabo correctamente. 

RBquerinisritos hadnae-y soflwne 

Esta seccion deberia determinar las herramientas software requeridas y la utilizacion estimada del 
hardware. 

Rastrlcdonas 

En esta seccion deberian anticiparse las restricciones que afectan al proceso de pruebas como la 
escasez de personal. 



Figura 22.4 

La estructura de un 

plan de pruebas. 
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sos estan disponibles para el equipo de pruebas. Los planes de pruebas normalmente de- 
berian incluir cantidades significativas de contingencias para que los desajustes en la im- 
plementacion y el diseno puedan solucionarse y el personal pueda ser reasignado a otras 
actividades. 

Para sistemas mas pequenos, se puede utilizarun plan de pruebas menos formal, pero si- 
gue siendo necesario un documento formal para soportar la planificacion del proceso de prue- 
bas. Para algunos procesos agiles como la programacion extrema, las pruebas son insepara- 
bles del desarrollo. Al igual que otras actividades de planificacion, la planificacion de las 
pruebas tambien es incremental. En XP, el cliente es el ultimo responsable de decidir cuanto 
esfuerzo deberia dedicarse a la prueba del sistema. 

Los planes de pruebas no son documentos estaticos, sino que evolucionan durante el pro- 
ceso de desarrollo. Los planes de pruebas cambian debido a retrasos en otras etapas del pro- 
ceso de desarrollo. Si parte de un sistema esta incompleto, el sistema no puede probarse como 
un todo. Entonces tiene que revisarse el plan de pruebas para volver a desplegar y a asignar a 
los encargados de las pruebas a alguna otra actividad, y recuperarlos cuando el software vuel- 
va a estar disponible. 

22.2 Inspecciones de software 

Las inspecciones de software son un proceso de V & V estatico en el que un sistema software 
se revisa para encontrar errores, omisiones y anomalias. Generalmente, las inspecciones se 
centran en el codigo fuente, pero puede inspeccionarse cualquier representacion legible del 
software como los requerimientos o un modelo de diseno. Cuando se inspecciona un sistema, 
se utiliza conocimiento del sistema, su dominio de aplicacion y el lenguaje de programacion 
o modelo de diseno para descubrir errores. 

Existen tres ventajas fundamentales de la inspeccion sobre las pruebas: 

1. Durante las pruebas, los errores pueden enmascarar (ocultar) otros errores. Cuando se 
descubre un error, nunca se puede estar seguro de si otras anomalias de salida son de- 
bidas a un nuevo error o son efectos laterales del error original. Debido a que la ins- 
peccion es un proceso estatico, no hay que preocuparse de las interacciones entre 
errores. Por lo tanto, una unica sesion de inspeccion puede descubrir muchos errores 
en un sistema. 

2. Pueden inspeccionarse versiones incompletas de un sistema sin costes adicionales. Si 
un programa esta incompleto, entonces se necesita desarrollar software de soporte es- 
pecializado para las pruebas a fin de probar aquellas partes que estan disponibles. Esto, 
obviamente, anade costes al desarrollo del sistema. 

3. Ademas de buscar los defectos en el programa, una inspeccion tambien puede consi- 
derar atributos de calidad mas amplios de un programa tales como grado de cumpli- 
miento con los estandares, portabilidad y mantenibilidad. Puede buscarse ineficien- 
cias, algoritmos no adecuados y estilos de programacion que podrian hacer que el 
sistema fuese dificil de mantener y actualizar. 

Las inspecciones son una idea antigua. Ha habido varios estudios y experimentos que han 
demostrado que las inspecciones son mas efectivas para descubrir defectos que las pruebas 
del programa. Fagan (Fagan, 1986) declaro que mas del 60% de los errores en un programa 
pueden detectarse utilizando inspecciones de programa informales. Mills y otros (Mills etal., 
1987) sugierenqueunaaproximacionmas formal de la inspeccion basada en lacorreccionde 
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los argumentos puede detectar mas del 90% de los errores en un programa. Esta tecnica se uti- 
liza en el proceso de Sala Limpia descrito en la Seccion 22.4. Selby y Basili (Selby et ah, 
1987) compararon empiricamente la efectividad de las inspecciones y de las pruebas. Obser- 
varon que la revision estatica de codigo era mas efectiva y menos costosa que las pruebas de 
defectos a la hora de encontrar defectos en los programas. Gilb y Graham (Gilb y Graham, 
1993) tambien encontraron que esto era cierto. 

Las revisiones y las pruebas tienen cada una sus ventajas e inconvenientes y deberian uti- 
lizarse conjuntamente en el proceso de verificacion y validacion. En realidad, Gilb y Graham 
sugieren que uno de los usos mas efectivos de las revisiones es la revision de los casos de prue- 
ba para un sistema. Las revisiones pueden descubrir problemas con estos tests y ayudar a di- 
senar formas mas efectivas para probar el sistema. Se puede empezar la V & V del sistema 
con inspecciones en etapas tempranas del proceso de desarrollo, pero una vez que se integra 
un sistema, se necesita comprobar sus propiedades emergentes y que la funcionalidad del sis- 
tema es la que su propietario realmente quiere. 

A pesar del exito de las inspecciones, se ha demostrado que es dificil introducir las ins- 
pecciones formales en muchas organizaciones de desarrollo de software. Los ingenieros de 
software con experiencia en la prueba de programas a menudo son reacios a aceptar que las 
inspecciones pueden ser mas efectivas para detectar defectos que las pruebas. Los gestores 
pueden ser reacios debido a que las inspecciones requieren costes adicionales durante el di- 
seno y el desarrollo. Pueden no querer asumir el riesgo de que no obtendran los correspon- 
dientes ahorros durante las pruebas de los programas. 

No hay duda de que las inspecciones sobrecargan al inicio los costes de V & V del soft- 
ware y conducen a un ahorro de costes solo despues de que los equipos de desarrollo adquie- 
ran experiencia en su uso. Ademas, hay problemas practicos en cuanto a la organizacion de 
las inspecciones: estas requieren tiempo para organizarse y parecen ralentizar el proceso de 
desarrollo. Es dificil convencer a un gestor muy presionado que este tiempo puede recuperarse 
mas tarde debido a que se tendra que emplear menos tiempo depurando el programa. 

22.2.1 □ proceso de Inspecclon de programas 

Las inspecciones de programas son revisiones cuyo objetivo es la deteccion de defectos en el 
programa. El concepto deun proceso de inspeccionformalizado se desarrollo porprimera vez 
por IBM en los aiios 70 (Fagan, 1976; Fagan, 1986). Actualmente es un metodo bastante uti- 
lizado de verificacion de programas, especialmente en ingenieriade sistemas criticos. Apar- 
tir del metodo original de Fagan, se han desarrollado varias aproximaciones alternativas de 
las inspecciones (Gilb y Graham, 1993). Todas ellas estanbasadas enungrupo con miembros 
que tienen diferentes conocimientos realizando una revision cuidadosa linea por linea del co- 
digo fuente del programa. 

La diferencia principal entre las inspecciones de programas y otros tipos de revisiones de 
calidad es que el objetivo primordial de las inspecciones es encontrar defectos en el progra- 
ma en lugar de considerar cuestiones de diseno mas generales. Los defectos pueden ser erro- 
res logicos, anomalias en el codigo que podrian indicar una condicion erronea, o el incum- 
plimiento de los estandares del proyecto o de la organizacion. Por otra parte, otros tipos de 
revision pueden estar mas relacionados con la agenda, los costes, el progreso frente a hitos 
definidos o la evaluacion de si es probable que el software cumpla los objetivos fijados por la 
organizacion. 

La inspeccion de programas es un proceso formal realizadoporun equipo de al menos cua- 
tro personas. Los miembros del equipo analizan sistematicamente el codigo y senalan posibles 
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Autor o propietario 


S projpamador o dseflador responsable de generar d programa o documento. Responsable de 
reparar los defectos descubiertos durante el proceso de inspection. 


Inspector 


Encuentra errores, omisiones e inconsistendas en los prograinas y documento*. Tambatn puede 
identiftcar cuestiones mas generates que estan fuera dd ambtodeteo^>odeinspe<d6n. 


Lector 


Pwenta «l codifo o documento en una reunion de inspection. 


Secretario 


Regtstra los resuftados de la reunion de mspeccion. 


Presiderrte o moderador 


Gestiona el proceso y fatifita la inspection. ReaKza un informs de los resultadosdef proceso pan 
e) moderador jefe. 


Moderador jefe 


Responsable de las mejoras del proceso de mspeccion, actualization de las Betas de comproba- 
don, estanderesde desarrollo, etc 



Figura 22.5 Roles en el proceso de inspeccion. 



defectos. En las propuestas originales de Fagan, se sugieren roles tales como autor, lector, pro- 
bador y moderador. El lector lee el codigo en voz alta al equipo de inspeccion, el probador ins- 
pecciona el codigo desde una perspectiva de prueba y el moderador organiza el proceso. 

A medida que las organizaciones ganan experiencia con la inspeccion, han surgido otras 
propuestas para los roles del equipo. En un estudio de como la inspeccion fue introducida con 
exito en el proceso de desarrollo de Hewlett-Packard, Grady y Van Slack (Grady y Van Slack, 
1994) sugieren seis roles, tal y como se muestra en la Figura 22.5. No creen que sea necesa- 
rio leer el programa en voz alta. La misma persona puede adoptar mas de un rol de forma que 
el tamano del equipo puede variar de una inspeccion a otra. Gilb y Graham sugieren que los 
inspectores deberian ser seleccionados para reflejar diferentes puntos de vista tales como 
pruebas, usuario final y gestion de la calidad. 

Las actividades en el proceso de inspeccion se muestran en la Figura 22.6. Antes de que 
comience una inspeccion del programa, es esencial que: 

1. Se tenga una especificacion precisa del codigo a inspeccionar. Es imposible inspec- 
cionar un componente a un nivel de detalle requerido para detectar defectos sin una 
especificacion completa. 

2. Los miembros del equipo de inspeccion esten familiarizados con los estandares de la 
organizacion. 

3. Se haya distribuido una vers ion compilable y actualizada del codigo a todos los miem- 
bros del equipo. No existe ningunarazon para inspeccionar codigo que este «casi com- 
pleto» incluso si un retraso provoca desfases en la agenda. 




Figura 22.6 El proceso de inspeccion. 
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El moderador del equipo de inspeccion es el responsable de laplanificacion de la inspec- 
cion. Esto implica seleccionarun equipo de inspeccion, organizaruna sala de reuniones y ase- 
gurar que el material a inspeccionar y sus especificaciones estan completas. El programa a ins- 
peccionar se presenta al equipo de inspeccion durante la etapa de revision general cuando el 
autor del codigo describe lo que el programa deberia hacer. A continuacion se precede a un 
periodo de preparacion individual. Cada miembro del equipo de inspeccion estudia la espe- 
cificacion y el programa y busca defectos en el codigo. 

La inspeccion en si misma deberia ser bastante corta (no mas de dos horas) y deberia cen- 
trarse en la deteccionde defectos, cumplimiento de los estandares y programaciondebajaca- 
lidad. El equipo de inspeccion no deberia sugerircomo deben repararse estos defectos ni re- 
comendar cambios en otros componentes. 

A continuacion de la inspeccion, el autor del programa deberia realizar los cambios para 
corregir los problemas identificados. En la etapa siguiente, el moderador deberia decidir si se 
requiere una reinspeccion de codigo. Puede decidir que no se requiere unareinspeccion com- 
pleta y que los defectos han sido reparados con exito. El programa entonces es aprobado por 
el moderador para su entrega. 

Durante una inspeccion, a menudo se utiliza una lista de comprobacion de errores de 
programacion comunes para centrar el analisis. Esta lista de comprobacion puede basarse 
en ejemplos de listas de comprobacion de libros o en conocimiento de los defectos que son 
comunes en un dominio de aplicacion particular. Se necesitan diferentes listas de compro- 
bacion para distintos lenguajes de programacion debido a que cada lenguaje tiene sus pro- 
pios errores caracteristicos. Humphrey (Humphrey, 1989), enun extenso estudio sobre las 
inspecciones, da varios ejemplos de listas de comprobacion para inspeccion. 

Esta lista de comprobacion varia de acuerdo con el lenguaje de programacion debido a los 
diferentes niveles de comprobacion proporcionados por el compilador del lenguaje. Porejem- 
plo, un compilador Java comprueba que las funciones tienen el numero correcto de parame- 
tros; un compilador C no lo hace. En la Figura 22.7 se muestran posibles comprobaciones que 
podrian realizarse durante un proceso de inspeccion. Gilb y Graham (Gilb y Graham, 1993) 
resaltan que cada organizacion deberia desarrollar su propia lista de comprobacion de ins- 
pecciones basada en estandares y practicas locales. Las listas de comprobacion deberian ser 
actualizadas regularmente a medida que se encuentran nuevos tipos de defectos. 

El tiempo necesario para una inspeccion y la cantidad de codigo que puede abarcar de- 
penden de la experiencia del equipo de desarrollo, el lenguaje de programacion y el dominio 
de la aplicacion. Tanto Fagan en I B M como Barnard y Price (Barnard y Price, 1994), quienes 
evaluaron el proceso de inspeccion para software de telecomunicaciones, llegan a conclusio- 
nes similares: 

1. Alrededor de 500 sentencias de codigo fuente por hora pueden presentarse durante la 
etapa de revision general. 

2. Durante la preparacion individual, pueden examinarse alrededor de 125 sentencias de 
codigo fuente por hora. 

3. Pueden inspeccionarse por hora de 90 a 125 sentencias durante la reunion de inspec- 
cion. 

Con cuatro personas involucradas en un equipo de inspeccion, el coste de inspeccionar 100 
lineas de codigo es aproximadamente equivalente a un esfuerzo de una persona-dia. Esto su- 
pone que la inspeccion en si misma lleva alrededor de una hora y que cada miembro del equi- 
po emplea de una a dos horas en preparar la inspeccion. Los costes de las pruebas son muy 
variables y dependen del numero de defectos en el programa. Sin embargo, el esfuerzo re- 
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Defectos de datos 



Defectos de control 



Defectos de 
entrada/salida 

Defectos de interfaz 



Figura 22.7 

Comprobaciones 
de inspeccion. 



Defectos de gestion 
de almacenamiento 



Defectos de manejo 
de excepciones 



iSe inkialtzan todas las variables antes de que se utilken sus valores? 
iTienen nombre todas las constantes? 

IB Hmrte superior de los vectores es igual al tamano del vector o al tamafto 21? 
Si se utiliian cadenas de caracteres, itienen un delimitador expllcitamente 
asignado? 

lExiste alguna posibilidad de que el bufer se desborde? 

Para cada sentencia conditional, ies correcta la condidon? 
iSe garantiza que termina cada bude? 

iEstan puestas correctamente entre Haves las sentencias compuestas? 
En las sentencias case, ise tienen en cuenta todos los posibles casos? 
Si se requiere una sentencia break despues de cada caso en las sentencias 
case, ise ha induido? 

iSe utilizan todas las variables de entrada? 

dSe Ies asigna un valor a todas las variables de salida? 

iPueden provocar corrupciones de datos las entradas no esperadas? 

iLas llamadas a fundones y a metodos tienen el numero correcto de para- 
metros? 

iConcuerdan los tipos de parametros reales y formales? 
iEstan en el orden correcto los parametros? 

Si los componentes acceden a memoria compartida, ttienefi el mismo mo- 
delo de estructura de la memoria compartida? 

Si una estructura enlazada se modifica, ise reasignan correctamente todos 
los enlaces? 

Si se utiliza almacenamiento dinamico, ise asigna correctamente el espado 
de memoria? 

iSe desasigna explfcitamente el espacio de memoria cuando ya no se nece- 
sita? 

iSe tienen en cuenta todas las condidones de error posibles? 



querido para la inspeccion de programas es probablemente menos de la mitad del esfiierzo que 
se requeriria para una prueba de defectos equivalente. 

Algunas organizaciones (Gilb y Graham, 1993) han abandonado actualmente la prueba de 
componentes en favor de las inspecciones. Han comprobado que las inspecciones de progra- 
mas son tan efectivas a la hora de encontrar errores que los costes de las pruebas de compo- 
nentes no son justificables. Estas organizaciones observan que las inspecciones de compo- 
nentes, combinados con las pruebas del sistema, son la estrategia de V & V mas rentable. Tal 
y como se indica mas adelante en el capitulo, esta aproximacion se utiliza en el proceso de 
desarrollo de software de SalaLimpia. 

La introduccionde las inspecciones tiene implicaciones para la gestion deproyectos. Una 
gestion sensibilizada es importante si las inspecciones tienen que ser aceptadas por los equi- 
pos de desarrollo del software. La inspeccion de programas es un proceso publico de detec- 
cion de errores comparado con el proceso mas privado de prueba de componentes. Inevita- 
blemente, los errores cometidos por individuos se muestran a todo el equipo de programacion. 
Los lideres de losequiposde inspeccion deben estar capacitados para gestionar el proceso cui- 
dadosamente y desarrollar una cultura que proporcione apoyo cuando se detectan errores y 
que no exista el sentimiento de culpa asociado a dichos errores. 

A medida que una organizacion gana experiencia en el proceso de las inspecciones, pue- 
de utilizar los resultados de estas para ayudar a la mejora del proceso. Las inspecciones son 
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una forma ideal de recopilar datos sobre el tipo de defectos que se producen. El equipo de ins- 
peccion y los autores del codigo que fue inspeccionado pueden sugerir razones de por que se 
introdujeron estos defectos. En donde sea posible, el proceso deberia entonces ser modifica- 
do para eliminar las razones de los defectos, de forma que estos puedan evitarse en sistemas 
futuros. 

223 Analisis estatico automatizado 

Las inspecciones son una forma de analisis estatico — se examina el programa sin ejecutar- 
lo — . Taly como se ha indicado, las inspecciones a menudo estan dirigidaspor listasde com- 
probacion de errores y heuristicas que identifican errores comunes en diferentes lenguajes de 
programacion. Paraalgunos errores y heuristicas, es posible automatizar el proceso decom- 
probacion de programas frente a estas listas, las cuales han propiciado el desarrollo de anali- 
zadores estaticos automatizados para diferentes lenguajes de programacion. 

Los analizadores estaticos son herramientas software que escanean el codigo fuente de un 
programa y detectan posibles defectos y anomali as. Analizan el codigo del programay asi re- 
conocen los tipos de sentencias en el programa. Pueden detectar si las sentencias estan bien 
formadas, hacer inferencias sobre el flujo de control del programa y, en muchos casos, cal- 
cular el conjunto de todos los posibles valores para los datos del programa. Complementan 
las facilidades de deteccion de errores proporcionadas por el compilador del lenguaje. Pue- 
den utilizarse como parte del proceso de inspeccion o como una actividad separada del pro- 
ceso V & V. 

El objetivo del analisis estatico automatizado es llamar laatenciondel inspector sobre las 
anomalias del programa, tales como variables que se utilizan sin inicializacion, variables que 
no se usan o datos cuyo valor podria estar fuera de alcance. Algunas de las comprobaciones 
que se pueden detectar mediante analisis estatico se muestran en la Figura 22.8. Las anoma- 
lias son a menudo el resultado de errores de programacion u omisiones, de forma que resal- 
ten aspectos del programa que podrian funcionarmal. Sin embargo, deberia comprenderse que 
estas anomalias no son necesariamente defectos en el programa. Pueden ser deliberadas o pue- 
den no tener consecuencias adversas. 



Figura 22.8 
Comprobaciones 
del analisis estatico 
automatizado. 
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Las etapas implicadas en el analisis estatico comprenden: 

1. Analisis del flujo de control. Esta etapa identifica y resalta bucles con multiples sali- 
das o puntos de entrada y codigo no alcanzable. El codigo no alcanzable es codigo que 
se salta con instrucciones goto no condicionales o que esta en una rama de una sen- 
tencia condicional en la que la condicion nunca es cierta. 

2. Analisis del uso de los datos. Esta etapa revela como se utilizan las variables del pro- 
grama. Detecta variables que se utilizan sin inicializacion previa, variables que se asig- 
nan dos veces y no se utilizan entre asignaciones, y variables que se declaran pero nun- 
ca se utilizan. El analisis del uso de los datos tambien descubre pruebas inutiles cuando 
la condicion de prueba es redundante. Las condiciones redundantes son condiciones 
que son siempre ciertas o siempre falsas. 

3. Analisis de interfaces. Este analisis comprueba la consistencia de las declaraciones de 
funciones y procedimientos y su utilizacion. No es necesario si se utiliza para la im- 
plementacion un lenguaje fuertemente tipado como Java, ya que el compilador lleva a 
cabo estas comprobaciones. El analisis de interfaces puede detectar errores de tipos en 
lenguajes debilmente tipados como FORTRAN y C. El analisis de interfaces tambien 
puede detectar funciones y procedimientos que se declaran y nunca son llamados o re- 
sultados de funciones que nunca se utilizan. 

4. Analisis del flujo de information. Esta fase del analisis identifica las dependencias en- 
tre las variables de entrada y salida. Mientras no detecte anomalias, muestra como se 
deriva el valor de cada variable del programa a partir de otros valores de variables. Con 
esta informacion, una inspeccion de codigo deberia sercapaz de encontrar valores que 
han sido calculados erroneamente. El analisis de flujo de informacion puede tambien 
mostrar las condiciones que afectan al valor de una variable. 

5. Analisis de caminos. Esta fase del analisis semantico identifica todos los posibles ca- 
minos en el programa y muestra las sentencias ejecutadas en dicho camino. Esencial- 
mente desenreda el control del programa y permite que cada posible predicado sea 
analizado individualmente. 

Los analizadores estaticos son particularmente valiosos cuando se utiliza un lenguaje de 
programacion como C. Este lenguaje no tiene reglas de tipos estrictas, y lacomprobacionque 
puede hacer el compilador de C es limitada. Por lo tanto, es facil para los programadores co- 
meter errores, y la herramienta de analisis estatico puede automaticamente descubriralgunos 
de los defectos de los programas. Esto es particularmente importante cuando C (y en menor 
medida C++) se utiliza para desarrollo de sistemas criticos. En este caso, el analisis estatico 
puede descubrir un gran numero de errores potenciales y reducir los costes de prueba de for- 
ma significativa. 

No hay duda de que, para lenguajes como C. el analisis estatico es una tecnica efectiva para 
descubrir errores en los programas. Este compensa los puntos debiles del diseflo del lengua- 
je de programacion. Sin embargo, los disefiadores de lenguajes de programacion modernos 
como Java han eliminado algunas caracteristicas propensas a error. Todas las variables deben 
ser inicial izadas; no hay sentencias goto, de modo que es menos probable crear codigo inal- 
canzable de forma accidental, y la gestion del almacenamiento es automatica. Esta aproxi- 
macion para evitar errores en lugar de detectar errores es mas efectiva a la hora de mejorar la 
fiabilidad del programa. Aunque hay disponibles analizadores estaticos para Java, no son am- 
pliamente usados. No esta claro si el numero de errores detectados justifica el tiempo reque- 
rido para analizar su salida. 
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Por lo tanto, para ilustrar el analisis estatico se utiliza un pequefio programa en C en lu- 
gar de un programa Java. Los sistemas Unix y Linux incluyen un analizador estatico 11a- 
mado LINT para programas en C. LINT proporciona comprobacion estatica, que es equi- 
valente a la proporcionada por el compilador en un lenguaje fuertemente tipado como Java. 
Un ejemplo de la salida producida por LINT se muestra en la Figura 22.9. En esta trans- 
cripcion de una sesion terminal de UNIX, los comandos se muestran en cursiva. La prime- 
ra linea de comandos (linea 138) lista el programa. Este define una funcion con un para- 
metro, denominado printarray, y a continuacion llama a esta funcion con tres parametros. 
Las variables j y c se declaran, pero nunca se Ies asigna ningun valor. El valor devuelto por 
la funcion nunca se utiliza. 

La linea 139 muestra la compilacion en C de este programa sin errores obtenido por el 
compilador de C. A continuacion se hace una llamada al analizador estatico LINT, que de- 
tecta y muestra los errores del programa. 

El analizador estatico muestra que las variables c e i han sido utilizadas pero no iniciali- 
zadas, y que printarray ha sido llamado con un numero diferente de argumentos que los de- 
clarados. Tambien identifica el uso inconsistente del primer argumento en printarray y el he- 
cho de que el valor de la funcion nunca se utiliza. 

El analisis basado en herramientas no puede sustituir a las inspecciones, ya que hay algu- 
nos tipos de error que los analizadores estaticos no pueden detectar. Por ejemplo, pueden de- 
tectar variables no inicial izadas, pero no pueden detectar inicializaciones incorrectas. En len- 
guajes debilmente tipados como C, los analizadores estaticos pueden detectar funciones que 
tienen numeros y tipos de argumentos erroneos, pero no pueden detectar situaciones en las que 
un argumento incorrecto del tipo correcto se ha pasado a una funcion. 

Para tratar algunos de estos problemas, analizadores estaticos tales como LCLint (Orcero, 
2000; Evans y Larochelle, 2002) soportan el uso de anotaciones en las que los usuarios defi- 
nen restricciones y comentarios con estilos en el programa. Estas restricciones permiten a un 

138% more Iint_ex.c 

•include <stdiah> 
printarray (Anarray) 
intAnarray; 

( 

print££%d" Anarray); 
J 

main 0 

{ 

int Anarrayf S); int i; char c; 
printarray (Anarray, i, c); 
printarray (Anarray); 

) 

139°/occKnt_exx 
140% lint lint_ex.c 

lint_ex.c(10): warning: c may be used before set 
Mnt_exx(10): warning: i may be used before set 
printarray: variable # of args. Mnt_ex.c(4):: fint_ex.c(10) 
printarray, arg. 1 used inconsistently lint_exc(4):: Iint_ex.c(10) 
printarray, arg 1 used inconsistently lint.exc(4):: lint_exc(ll) 
printf returns value which is always ignored 



Figura 22.9 

Analisis estatica LINT. 
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programador especificarque variables en una funcion no deberian cambiar, las variables glo- 
bales a utilizar, y asi sucesivamente. El analizador estatico puede a continuacion comprobar 
el programa frente a esas restricciones y resaltar secciones de codigo que parezcan estar in- 
correctas. 

22.4 Verificacion y metodos formales 

Los metodos formales de desarrollo del software se basan en representaciones matematicas 
del software, normalmente como una especificacion formal. Estos metodos formales se ocu- 
pan principalmente del analisis matematico de la especificacion; de transformar la especifi- 
cacion a una representacion mas detallada semanticamente equivalente; o de verificar for- 
malmente que una representacion del sistema es semanticamente equivalente a otra 
representacion. 

Usted puede pensaren el uso de metodos formales como la tecnica ultima de verificacion 
estatica. Los metodos formales requieren un analisis muy detallado de la especificacion del 
sistema y del programa, y su uso consume a menudo tiempo y resulta caro. Como conse- 
cuencia, el uso de metodos formales esta restringido principalmente a los procesos de des- 
arrollo de software de seguridad critico y seguro. El uso de especificaciones matematicas for- 
males y la verificacion asociada fue encargado en los estandares de defensa en el Reino Unido 
para software de seguridad critico (MOD, 1995). 

Los metodos formales pueden utilizarse en diferentes etapas en el proceso V & V: 

1 . Puede desarrollarse una especificacion formal del sistema y analizarse matematica- 
mente para buscar inconsistencias. Esta tecnica es efectiva para descubrir errores y 
omisiones de especificacion, tal y como se explico en el Capitulo 10. 

2. Puede verificarse formalmente, utilizando argumentos matematicos, que el codigo de 
un sistema software es consistente con su especificacion. Esto requiere una especifi- 
cacion formal y es efectiva para descubrir algunos errores de diseno y programacion. 
Puede utilizarse un proceso de desarrollo transformacional o proceso de Sala Limpia 
en el que una especificacion formal se transforma a traves de una serie de representa- 
ciones mas detalladas para soportar el proceso de verificacion formal. 

El argumento para el uso de la especificacion formal y de la verificacion del programa aso- 
ciado es que la especificacion formal fuerzaun analisis detallado de la especificacion. Puede 
revelar inconsistencias u omisiones potenciales que podrian de otra forma no ser descubier- 
tas hasta que el sistema sea operacional. La verificacion formal demuestra que el programa 
desarrollado satisface su especificacion, por lo que los errores de implementacion no com- 
prometen la confiabilidad. 

El argumento en contra del uso de la especificacion formal es que requiere notaciones es- 
pecializadas. Estas solo se pueden utilizar por personal entrenado especialmente y no pueden 
ser comprendidas por expertos del dominio. Por lo tanto, los problemas con los requerimien- 
tos del sistema pueden estar encubiertos por la formalidad. Los ingenieros software no pue- 
den reconocer dificultades potenciales con los requerimientos debido a que no comprenden 
el dominio; los expertos en el dominio no pueden encontrar estos problemas porque no com- 
prenden la especificacion. Aunque la especificacion puede ser matematicamente consistente, 
puede no especificar las propiedades del sistema que son realmente necesarias. 

Verificar un software no trivial consume una gran cantidad de tiempo y requiere herra- 
mientas especializadas tales como demostradores de teoremas y expertos matematicos. Por lo 
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tanto, es un proceso extremadamente caro y, a medida que el tamano del sistema crece, los 
costes de la verificacion formal crecen desproporcionadamente. En consecuencia, mucha gen- 
re piensa que la verificacion formal no es muy rentable. El mismo nivel de confianza en el sis- 
tema puede lograrse de forma mas economica utilizando otras tecnicas de validacion como 
las inspecciones y pruebas de sistemas. 

Se ha dicho algunas veces que el uso de metodos formales para el desarrollo de sistemas 
conduce a sistemas mas fiables y seguros. No hay duda de que una especificacion formal de 
un sistema es menos probable que contenga anomalias que tengan que resolverse por el dise- 
nadordel sistema. Sin embargo, la especificacion formal y la demostracion no garantizaque 
el software sera fiable en el uso practico. Las razones de esto son las siguientes: 

1. La especificacion puede no reflejar los requerimientos reales de los usuarios del sis- 
tema. Lutz (Lutz, 1993) descubrio que muchos fallos experimentados por los usua- 
rios eran consecuencia de errores y omisiones en la especificacion, que podrian no 
haberse detectado por una especificacion formal del sistema. Ademas, los usuarios 
del sistema raramente comprenden las notaciones formales, por lo que no pueden leer 
directamente la especificacion formal para encontrar errores y omisiones. 

2 . La demostracion puede contener errores. Las demostraciones de los programas son 
largas y complejas; por lo tanto, al igual que los programas complejos y grandes, nor- 
malmente contienen errores. 

3. La demostracion puede asumir un patron de uso que es incorrecto. Si el sistema no se 
usa tal y como se ha anticipado, la demostracion puede ser invalida. 

A pesar de sus desventajas, la opinion que aqui se formula (expuesta en el Capitulo 10) es 
que los metodos formales juegan un papel importante en el desarrollo de sistemas software 
criticos. Las especificaciones formales son muy efectivas descubriendo problemas de la es- 
pecificacion que son las causas mas comunes de los fallos de ejecucion del sistema. La veri- 
ficacion formal incrementa la confianza en los componentes mas criticos de estos sistemas. 
El uso de aproximaciones formales va en aumento a medida que los clientes lo solicitan y a 
medida que cada vez mas ingenieros estan mas familiarizados con estas tecnicas. 

22.4.1 Desarrollo de software de Sala Llmpla 

Los metodos formales se han integrado con varios procesos de desarrollo del software. En el 
metodo B (Wordsworth, 1996), una especificacion formal setransformaenunprogramaatra- 
ves de una serie de transformaciones que preservan la correccion. SDL (Mitschele-Thiel, 
2001) se usa para el desarrollo de sistemas de telecomunicaciones y V D M (Jones, 1986) y Z 
(Spivey, 1992) han sido utilizados en procesos del tipo en cascada. Otra aproximacion bien 
documentada que utiliza metodos formales es el proceso de desarrollo de Sala Limpia. El des- 
arrollo de software de Sala Limpia (Mills et al, 1987; Cobb y Mills, 1990; Linger, 1994; Pro- 
well etal., 1999) es una filosofia de desarrollo de software que utiliza metodos formales para 
soportar inspecciones del software rigurosas. 

Un modelo del proceso de Sala Limpia se muestraen la Figura 22.10. El objetivo de esta 
aproximacion de desarrollo del software es obtener software con cero defectos. El nombre 
«Sala Limpia» se derivo de la analogia con la fabricacion de unidades de semiconductores 
en donde los defectos se evitaban mediante su fabricacion en una atmosfera ultralimpia. El 
desarrollo de Sala Limpia es particularmente pertinente en este capitulo, debido a que reem- 
plaza las pruebas de unidades de los componentes del sistema por inspecciones para com- 
probar la consistencia de estos componentes con sus especificaciones. 
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Figura 22.10 El proceso de desarrollo de Sala Limpia. 



La aproximacion de Sala Limpia al desarrollo del software se basa en cinco estrategias 
clave: 

1 . Especificacion forma!. El software a desarrollar se especifica formalmente. Para ex- 
presar la especificacion se utiliza un modelo de transicion de estados que muestra las 
respuestas del sistema a los estimulos. 

2. Desarrollo incremental. El software se divide en incrementos que se desarrollan y va- 
lidan de forma independiente utilizando el proceso de Sala Limpia. Estos incrementos 
se especifican, con la informacion de los clientes, en una etapa temprana del proceso. 

3. Programacion estructurada. Se utiliza solo un numero limitado de estructuras de con- 
trol y de abstracciones de datos. El proceso de desarrollo del programa es un proceso 
de pasos de refinamiento de la especificacion. Se utiliza un numero limitado de cons- 
trucciones y el objetivo es transformar sistematicamente la especificacion paracrear 
el codigo del programa. 

4. Verificacion estdtica. El software desarrollado se verifica estaticamente utilizando ins- 
pecciones de software rigurosas. No existe ningun proceso de prueba de unidades o 
modulos para los componentes del codigo. 

5. Pruebas estadisticas de! sistema. E 1 incremento del software integrado es probado es- 
tadisticamente, tal y como se explica en el Capitulo 24, para determinar su fiabilidad. 
Estas pruebas estadisticas se basan en un perfil operacional, el cual se desarrolla en pa- 
ralelo con la especificacion del sistema, tal y como se muestra en la Figura 22. 10. 

Existen tres equipos implicados cuando se utiliza el proceso de Sala Limpia para el desa- 
rrollo de grandes sistemas: 

1. El equipo de especificacion. Este grupo es responsable del desarrollo y mantenimien- 
to de la especificacion del sistema. Este equipo produce especificaciones orientadas al 
cliente (la definicion de requerimientos del usuario) y especificaciones matematicas 
para verificacion. En algunos casos, cuando la especificacion es completa, el equipo 
de especificacion tambien toma la responsabilidad del desarrollo. 

2. Ei equipo de desarrollo. Este equipo tiene la responsabilidad de desarrollar y verifi- 
car el software. El software no se ejecuta durante el proceso de desarrollo. Se utiliza 
una aproximacion formal y estructurada para la verificacion basada en inspeccion de 
codigo y complementada con argumentos de correccion. 

3. El equipo de certificacidn. Este equipo se encarga de desarrollar un conjunto de prue- 
bas estadisticas para ejercitar el software despues de que haya sido desarrollado. Es- 
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tas pruebas se basan en especificacion formal. El desarrollo de los casos de prueba se 
lleva a cabo en paralelo con el desarrollo del software. Los casos de prueba se utilizan 
para certificar la fiabiudad del software. Los modelos de crecimiento de fiabilidad (Ca- 
pitulo 24) pueden utilizarse para decidir cuando parar las pruebas. 

El uso de la aproximacion de Sala Limpia conduce generalmente a software con muy po- 
cos errores. Coob y Mills analizan varios proyectos de desarrollo con exito de Sala Limpia 
que tuvieron una tasa de fallos de funcionamiento muy baja en los sistemas entregados (Coob 
y Mills, 1990). Los costes de estos proyectos fueron comparables a otros proyectos que usa- 
ron tecnicas de desarrollo convencionales. 

La aproximacion al desarrollo incremental en el proceso de Sala Limpia consiste en en- 
tregar funcionalidades criticas del cliente en incrementos tempranos. Las funciones del siste- 
ma menos importantes se incluyen en incrementos posteriores. Por lo tanto, el cliente tiene la 
oportunidad de probar estos incrementos criticos antes de que se haya entregado el sistema en 
su totalidad. Si se descubren problemas con estos incrementos, el cliente comunica esta in- 
formacion al equipo de desarrollo y solicita una nueva entrega del incremento. 

Al igual que ocurre con laprogramacion extrema, esto significa que las funciones del clien- 
te mas importantes reciben la mayor parte de la validacion. Amedidaque se desarrollan nue- 
vos incrementos, estos se combinan con los requerimientos existentes y se prueba el sistema 
integrado. Por lo tanto, los requerimientos existentes se vuelven a probar con nuevos casos de 
prueba a medida que se afiaden nuevos incrementos al sistema. 

La inspeccion rigurosa de programas es una parte fundamental del proceso de Sala Lim- 
pia. Se produce un modelo de estados del sistema como una especificacion del sistema. Este 
se refina a traves de una serie de modelos del sistema mas detallados hasta conseguirun pro- 
grama ejecutable. La aproximacion utilizada para el desarrollo se basa en transformaciones 
bien definidas que intentan preservar la correccion de cada transformacion a una representa- 
cion mas detallada. En cada etapa se inspecciona la nueva representacion, y se desarrollan ar- 
gumentos matematicamente rigurosos para demostrar que la salidade la informaciones con- 
sistente con su entrada. 

Los argumentos matematicos utilizados en el proceso de Sala Limpia no son, sin embar- 
go, demostraciones formales de correccion. Las demostraciones matematicas formales de que 
un programa es correcto con respecto a su especificacion son demasiado caras de llevar a cabo. 
Dependen del uso del conocimiento sobre la semantica formal del lenguaje de programacion 
para construir teorias que relacionan el programa y su especificacion formal. A continuacion 
estas teorias deben probarse matematicamente, a menudo con la asistencia de grandes y com- 
plejos programas de demostradores de teoremas. Debido a su alto coste y a que se necesitan 
habilidades especiales, las demostraciones se desarrollan normalmente solo para la mayoria 
de las aplicaciones de seguridad o de proteccion criticas. 

Se ha observado que la inspeccion y el analisis formal son muy efectivos en el proceso de 
Sala Limpia. La inmensa mayoria de los defectos se descubren antes de la ejecucion y no se 
introducen en el software desarrollado. Linger (Linger, 1994) muestraque, enpromedio, solo 
2,3 defectos por mil lineas de codigo fuente fueron descubiertos durante las pruebas para pro- 
yectos de Sala Limpia. Los costes totales de desarrollo no se incrementaron debido a que se 
requirio menos esfuerzo para probar y reparar el software desarrollado. 

Selby y otros (Selby etal., 1987), utilizando estudiantes como desarrolladores, llevaron a 
cabo un experimento que comparaba el desarrollo de Sala Limpia con tecnicas convenciona- 
les. Comprobaron que la mayoria de los grupos pudieron usar con exito el metodo de Sala 
Limpia. Los programas producidos fueron de mayor calidad que los desarrollados utilizando 
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tecnicas tradicionales; el codigo fuente tuvo mas comentarios y una estructura mas simple. 
Muchos de los equipos de Sala Limpia cumplieron la agenda de desarrollo. 

El desarrollo de Sala Limpia funciona bien cuando se practica por ingenieros comprome- 
tidos y habilidosos. Los informes sobre el exito de la aproximacion de Sala Limpia en la in- 
dustria provienen en su mayoria, aunque no de forma exclusiva, de gente que ya lo habia uti- 
lizado. No se sabe si este proceso puede transferirse de forma efectiva a otros tipos de 
organizaciones de desarrollo de software. Estas organizaciones pueden tener ingenieros me- 
nos comprometidos y menos habilidosos. La transferencia de la aproximacion de Sala Lim- 
pia, o en realidad de cualquier otra aproximacion en la que se utilicen metodos formales, a or- 
ganizaciones menos avanzadas tecnicamente, todavia continua siendo un reto. 



PUNTOS CLAVE 

• Laverificacionylavalidacionnosonlomismo. La verif icacion intenta mostrar que un programa satisface su 
especificacion. Lavalidacion intenta mostrar que el programa hace loqueelusuariorequiere. 

• Los planes de pruebas deberian incluirunadescripcion de los elementos que hay que probar, la agenda de 
pruebas, tos procedimientos para gestionar el proceso de pruebas, los requerimientos hardware y software, 
y cualquier problema de pruebas que probablemente pueda surgir. 

• Las tecnicas de verif icacion estatica implican examinaryanalizarelcod i go fuente del programa paradetectar 
errores. Deberian utilizarse con las pruebas de programas como parte del proceso V & V. 

Las inspecciones de programas son efectivas para encontrar errores en los programas. El objetivo de una Ins- 
peccion es localizar defectos. Una lista de comprobacion de defectos deberia conducir el proceso de la ins- 
pection. 

• En una inspeccion de programas, un grupo peq u enocompruebaelcodigodeformasistematica. Los miembros 
del equipo incluyen un lider del equipo o moderador, el autordel codigo, un lector que presenta el codigo du- 
rante la inspeccion yun probadorque considera el codigo desde una perspectiva de pruebas. 

Los analizadores estaticos son herramientas software que procesan un codigo fuente de un programa y po- 
nen de manifiesto anomali'astales co mo seccionesdecodigo no utilizadasy variables sin iniciatizar. Estas a no- 
ma Has pueden ser el resultado de defectos en el cod i go . 

• El desarrollo de software de Sala Limpia se centra en tecnicas estaticas para la verif icacion de programas y 
pruebas es tad i st icas para la cert if icacion de ta Habilidad del sistema. Se ha utilizado con exito en ta produc- 
ciondesistemasquetienenunaltoniveldehabilidad. 
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Software Quality Assurance: From Theory to Implementation. Este libro proporciona una buena lectura de base so- 
bre la verif icacion y va I id ac ion . con uncap it ulo particularmente bueno sobre revisiones e inspecciones. (D. Gal in, 
2004, Addison-Wesley.) 
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«Software inspection". Un numero especial de una revista que contiene varios artfculos sobre inspeccion de pro- 
gramas, incluyendo una discusion del uso de dicha tecnica con desarrollo orientado a objetos. {ieee Software, 
2 °(4)> julio-agosto de 2003.] 

«Software debugging, testing and verification". Este es un artfculo general sobre verificacion y validacion y uno de 
los pocos artfculos que tratan las tecnicas de pruebas y verificacion estatica. [B. Halipern y P. Santhanam, IBM 

Systems Journal, 41(1), enero de 2002.] 

Cteanroom Software Engineering: Technology and Process. Un buen libit) sobre la aproximacion de Sala Limpia que 
contiene secciones sobre los fundamentos de dicha tecnica, el proceso y un caso de estudio practice (S. j. Powell 
ef al, 1999, Addison-Wesley.) 



EJERCICIOS 



22.1 Senate las diferencias entre verificacion y validacion, y explique por que la validacion es un proceso parti- 
cularmente diffcil. 

22.2 Explique por q ue no es necesario que un programa este completamente libre de defectos antes de que sea 
entregado a sus clientes. ^Hasta donde se pueden utilizar las pruebas para validarque el programa cum- 
ple con su proposito? 

22.3 □ plan de pruebas de (a Figura 224 ha sido disenado para sistemas a medida que tienen un documento 
de requerimientos independiente. Sugiera como podrfa modificarse la estructura del plan de pruebas para 
probar productos software comerciales. 

224 Explique por que las inspecciones de programas son una tecnica efectiva para descubrir errores en un pro- 
grama. iQue tipos de errores probablemente no sean descubiertos a traves de las inspecciones? 

22.5 Sugiera por que una organizacion con una cultura elitista y competitiva podna probablemente encontrar 
diffcil introducir las inspecciones de programas como una tecnica de V & V. 

22.6 Utilizando su conocimiento de Java, C++, C o cualquier otro lenguaje de programacion, derive una lista de 
com probacion de errores comunes (no errores sintacticos) que podrfan no ser detectados por un compi- 
lador, pero que podrfan ser detectados en una inspeccion de programas. 

22.7 Genere una lista de condiciones que podrfan ser detectadas por un analizador estatico para Java, C++ u otro 
lenguaje de programacion que usted utilice. Comente esta lista comparada con la lista dada en la Figu- 
ra 22.7. 

22.8 Explique por que puede ser rentable utilizar metodos formales en el desarrollo de sistemas software de 
seguridad crfticos. £Por que piensa usted que algunos desarrolladores de este tipo de sistemas estan en 
contra del uso de los metodos formales? 

22.9 Un gestor decide utilizar los informes de tas inspecciones de programas como entrada para el proceso de 
valoracion del personal. Estos informes muestran quien hace y quien descubre los errores en los progra- 
mas. i,Es este un comportamiento de gestion etico? ^Podrfa ser etico si el personal fuese informado con 
antelacion de que esto podna ocurrir? iQue diferencia se podrfa generar en el proceso de inspeccion? 

22.10 Una aproximacion comunmente adoptada para (as pruebas del sistema es probar el sistema hasta que se 
agote el presupuesto de pruebas y entonces se entrega el sistema a los clientes. Comente la etica de esta 
aproximacion. 



23 

Pruebas 
del software 



Objetivos 

□ objetivo de este capftulo es describir el proceso de las pruebas 
del software e introducir varias tecnicas de pruebas. Cuando haya 
lei'do este capftulo: 

• comprendera las diferencias entre pruebas de validation y 
pruebas de defectos; 

• comprendera los principios de las pruebas del sistema y las 
pruebas de componentes; 

• comprendera ties estrateglas que pueden utilizarse para 
generar casos de pruebas del sistema; 

• comprendera las caracteristicas esenciales de las herramientas 
software que soportan la automatizacion de las pruebas. 
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23.2 Pruebas de componentes 
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En el Capitulo 4 se describio un proceso general de pruebas que comenzaba con la prueba 
de unidades de programas individuales tales como funciones u objetos. A continuacion, es- 
tas se integraban en subsistemas y sistemas, y se probaban las interacciones entre estas uni- 
dades. Finalmente, despues de entregar el sistema, el cliente puede llevar a cabo una serie 
de pruebas de aceptacion para comprobarque el sistema funciona tal y como se ha especi- 
ficado. 

Este modelo de proceso de pruebas es apropiado para el desarrollo de sistemas grandes; 
pero para sistemas mas pequenos, o para sistemas que se desarrollan mediante el uso de 
scripts o reutilizacion, a menudo se distinguen menos etapas en el proceso. Una vision mas 
abstracta de las pruebas del software se muestra en la Figura 23. 1 . Las dos actividades fun- 
damentales de pruebas son la prueba de componentes — probar las partes del sistema — y 
la prueba del sistema — probar el sistema como un todo. 

El objetivo de la etapa de la prueba de componentes es descubrir defectos probando com- 
ponentes de programas individuales. Estos componentes pueden ser funciones, objetos o com- 
ponentes reutilizables, tales como los descritos en el Capitulo 19. Durante las pruebas del sis- 
tema, estos componentes se integran para formar subsistemas o el sistema completo. En esta 
etapa, la prueba del sistema deberia centrarse en establecer que el sistema satisface sus re- 
querimientos funcionales y no funcionales, y no se comporta de forma inesperada. Inevita- 
blemente, los defectos en los componentes que no se han detectado durante las primeras eta- 
pas de las pruebas se descubren durante las pruebas del sistema. 

Tal y como se ha explicado en el Capitulo 22, el proceso de pruebas del software tiene dos 
objetivos distintos: 

1 . Para demostrar al desarrollador y al cliente que el software satisface sus requerl- 
mlentos. Para el software a medida, esto significa que deberia haber al menos una prue- 
ba para cada requerimiento de los documentos de requerimientos del sistema y del 
usuario. Para productos de software genericos, significa que deberia haber pruebas 

para todas las caracteristicas del sistema que se incorporaran en la entrega del pro- 
ducto. Tal y como se explico en el Capitulo 4, algunos sistemas pueden teneruna fase 
de pruebas de aceptacion explicita en la que el cliente comprueba formalmente que el 
sistema entregado cumple su especificacion. 

2. Para descubrir defectos en el software en que el comportamlento de este es Incorrec- 
to, no deseable ono cumple su especificacion. L a prueba de defectos esta relacionada 

con la eliminacion de todos los tipos de comportamientos del sistema no deseables, ta- 
les como caidas del sistema, interacciones no permitidas con otros sistemas, calculos 
incorrectos y corrupcion de datos. 

El primer objetivo conduce a las pruebas de validacion, en las que se espera que el siste- 
ma funcione correctamente usando un conjunto determinado de casos de prueba que reflejan 
el uso esperado de aquel. El segundo objetivo conduce a la prueba de defectos, en los que los 
casos de prueba se disenan para exponer los defectos. Los casos de prueba pueden ser deli- 
beradamente oscuros y no necesitan reflejar como se utiliza normalmente el sistema. Para las 
pruebas de validacion, una prueba con exito es aquella en la que el sistema funciona corree- 
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lamente. Para las pruebas de defectos, una prueba con exito es aquella que muestra un defec- 
to que hace que el sistema funciona incorrectamente. 

Las pruebas no pueden demostrar que el software esta libre de defectos o que se compor- 
tara en todo momento como esta especificado. Siempre es posible que una prueba que se haya 
pasado por alto pueda descubrir problemas adicionales con el sistema. Como dijo de forma 
elocuente Edsger Dijkstra. una de las primeras figuras lideres en el desarrollo de la ingenie- 
ria del software (Dijkstra el al. 1972). «las pruebas solo pueden demostrar la presencia de 
errores, no suausencia». 

Generalmente, por lo tanto, el objetivo de las pruebas del software es convencer a los desa- 
rrolladores del sistema y a los clientes de que el software es lo suficientemente bueno para su 
uso operacional. La prueba es un proceso que intenta proporcionar confianza en el software. 

Unmodelo general del proceso de pruebas se muestra en laFigura 23.2. Los casos de prue- 
ba son especificaciones de las entradas para la prueba y la salida esperada del sistema mas una 
afirmacion de lo que se esta probando. Los datos de prueba son las entradas que han sido ide- 
adas para probar el sistema. Los datos de prueba a veces pueden generarse automaticamente. 
La generacion automatica de casos de prueba es imposible. Las salidas de las pruebas solo 
pueden predecirse por personas que comprenden lo que deberia hacer el sistema. 

Las pruebas exhaustivas, en las que cada posible secuencia de ejecucion del programa es 
probada, son imposibles. Las pruebas, por lo tanto, tienen que basarse en un subconjunto de 
posibles casos de prueba. Idealmente, algunas companias deberian tenerpoliticas para elegir 
este subconjunto en lugar de dejar esto al equipo de desarrollo. Estas politicas podrian basar- 
se en politicas generales de pruebas, tal como una politica en la que todas las sentencias de 
los programas deberian ejecutarse al menos una vez. De forma alternativa, las politicas de 
pruebas pueden basarse en la experiencia de uso del sistema y pueden centrarse en probar las 
caracteristicas del sistema operacional. Por ejemplo: 

1. Deberian probarse todas las funciones del sistema a las que se accede a traves de 
menus. 

2. Deben probarse todas las combinaciones de funciones (por ejemplo, formateado de 
textos) a las que se accede a traves del mismo menu. 

3. En los puntos del programa en los que el usuario introduce datos, todas las funciones 
deben probarse con datos correctos e incorrectos. 

A partir de la experiencia con los principales productos de software tales como procesa- 
dores de texto u hojas de calculo, esta claro que durante el uso del producto se utilizan nor- 
malmente guias similares durante las pruebas de los productos. Cuando se usan las caracte- 
risticas del software por separado, estas normalmente funcionan. Los problemas surgen, tal y 
como explica Whittaker (Whittaker, 2002), cuando no se han probado conjuntamente combi- 
naciones de caracteristicas. El pone el ejemplo de como, en un procesadorde texto comun- 
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mente usado, el uso de notas al pie de pagina con un formato a dos columnas provoca un for- 
mateado incorrecto del texto. 

Como una parte del proceso V & V, los gestores tienen que tomar decisiones sobre quien 
deberia ser responsable de las diferentes etapas de las pruebas. Para la mayoria de los siste- 
mas, los programadores tienen la responsabilidad de probar los componentes que ellos han 
desarrollado. Una vez que lo hacen, el trabajo se pasa a un equipo de integracion que integra 
los modulos de diferentes desarrolladores, construye el software y prueba el sistema como un 
todo. Para sistemas criticos, puede utilizarse un proceso mas formal en el que probadores in- 
dependientes son responsables de todas las etapas del proceso de prueba. En pruebas de sis- 
temas criticos, las pruebas se desarrollan de forma independiente y se mantienen informes de- 
tallados de los resultados de las mismas. 

Las pruebas de componentes realizadas por los desarrolladores se basan normalmente 
en una comprension intuitiva de como los componentes deberian operar. Las pruebas del 
sistema, sin embargo, tienen que basarse en una especificacion escrita del sistema. Esta 
puede ser una especificacion detallada de requerimientos del sistema, tal y como se indi- 
co en el Capitulo 6, o puede ser una especificacion orientada al usuario de mas alto nivel 
de las caracteristicas que deberia implementar el sistema. Normalmente un grupo inde- 
pendiente es responsable de las pruebas del sistema. Tal y como se explico en el Capitulo 
4, el equipo de pruebas del sistema trabaja a partir de los documentos de requerimientos 
del sistema y del usuario para desarrollar los planes de pruebas del sistema (vease la Fi- 
gura 4. 1 0). 

La mayoria de los tratamientos de pruebas comienzan con las pruebas de componentes y 
a continuacion se realizan las pruebas del sistema. Se ha invertido de forma deliberada el or- 
den de la exposicion en este capitulo debido a que cada vez mas el desarrollo del software im- 
plica integrar componentes reutilizables y configurar y adaptar software existente para satis- 
facer requerimientos especificos. Todas las pruebas en tales casos son pruebas del sistema, y 
no hay un proceso separado de pruebas de componentes. 

23.1 Pruebas del sistema 

Las pruebas del sistema implican integrar dos o mas componentes que implementan funcio- 
nes del sistema o caracteristicas y a continuacion se prueba este sistema integrado. En un pro- 
ceso de desarrollo iterativo, las pruebas del sistema se ocupan de probar un incremento que 
va a ser entregado al cliente; en un proceso en cascada, las pruebas del sistema se ocupan de 
probar el sistema completo. 

Para la mayoria de los sistemas complejos, existen dos fases distintas de pruebas del sis- 
tema: 

1. Pruebas de integracion, en las que el equipo de pruebas tiene acceso al codigo fuen- 
te del sistema. Cuando se descubre un problema, el equipo de integracion intenta en- 
contrar la fuente del problema e identificar los componentes que tienen que ser depu- 
rados. Las pruebas de integracion se ocupan principalmente de encontrar defectos en 
el sistema. 

2. Pruebas de entregas, en las que se prueba una version del sistema que podria ser en- 
tregada a los usuarios. Aqui, el equipo de pruebas se ocupa de validar que el sistema 
satisface sus requerimientos y con asegurar que el sistema es confiable. Las pruebas 
de entregas son normalmente pruebas de «caja negra» en las que el equipo de pruebas 
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se ocupa simplemente de demostrar si el sistema fiinciona o no correctamente. Los 
problemas son comunicados al equipo de desarrollo cuyo trabajo es depurar el pro- 
grama. Cuando los clientes se implican en las pruebas de entregas, estas a menudo se 
denominanpruebas de aceptacion. Si la entrega es lo suficientemente buena, el clien- 
te puede entonces aceptarla para su uso. 

Fundamentalmente, se puede pensar en las pruebas de integracion como las pruebas de sis- 
temas incompletos compuestos por grupos de componentes del sistema. Las pruebas de en- 
tregas consisten en probar la entrega del sistema que se pretende proporcionar a los clientes. 
Naturalmente, estas se solapan, en especial cuando se utiliza desarrollo incremental y el sis- 
tema para entregar esta incompleto. Generalmente, la prioridad en las pruebas de integracion 
es descubrir defectos en el sistema, y la prioridad en las pruebas del sistema es validar que el 
sistema satisface sus requerimientos. Sin embargo, en la practica, hay una parte de prueba de 
validacion y una parte de prueba de defectos durante ambos procesos. 

23.1.1 Pruebas de integracion 

El proceso de la integracion del sistema implica construir este a partir de sus componentes 
(vease el Capitulo 29) y probar el sistema resultante para encontrar problemas que pueden sur- 
gir debido a la integracion de los componentes. Los componentes que se integran pueden ser 
componentes comerciales, componentes reutilizables que han sido adaptados a un sistema 
particular, o componentes nuevos desarrollados. Para muchos sistemas grandes, es probable 
que se usen los tres tipos de componentes. Las pruebas de integracion comprueban que estos 
componentes realmente funcionan juntos, son llamados correctamente y transfieren los datos 
correctos en el tiempo preciso a traves de sus interfaces. 

La integracion del sistema implica identificar grupos de componentes que proporcionan al- 
guna funcionalidad del sistema e integrar estos afiadiendo codigo para hacer que funcionen 
conjuntamente. Algunas veces, primero se desarrolla el esqueleto del sistema en su totalidad, 
y se le afiaden los componentes. Esto se denomina integracion descendente. De forma alter- 
nativa, pueden integrarse primero los componentes de infraestructura que proporcionan ser- 
vicios comunes, tales como el acceso a bases de datos y redes, y a continuacion pueden afia- 
dirse los componentes funcionales. Esta es la integracion ascendente. En la practica, para 
muchos sistemas, la estrategia de integracion es una mezcla de ambas, anadiendo en incre- 
mentos componentes de infraestructura y componentes funcionales. En ambas aproximacio- 
nes de integracion, normalmente tiene que desarrollarse codigo adicional para simularotros 
componentes y permitir que el sistema se ejecute. 

La principal dificultad que surge durante las pruebas de integracion es la localizacion 
de los errores. Existen interacciones complejas entre los componentes del sistema, y cuan- 
do se descubre una salida anomala, puede resultar dificil identificar donde ha ocurrido el 
error. Para hacer mas facil la localizacion de errores, siempre deberia utilizarse una apro- 
ximacion incremental para la integracion y pruebas del sistema. Inicialmente, deberia in- 
tegrarse una configuracion del sistema minima y probar este sistema. A continuacion, de- 
berian afiadirse componentes a esta configuracion minima y probar despues de afiadir cada 
incremento. 

En el ejemplo mostrado en la Figura 23.3, A, B, C y D son componentes, y desde TI has- 
ta T5 son conjuntos de pruebas relacionados de las caracteristicas incorporadas al sistema. T I , 
T2 y T3 se ejecutan primero sobre un sistema formado por los componentes A y B (el siste- 
ma minimo). Si tales componentes revelan defectos, estos se corrigen. El componente C se 
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integra y TI, T2 y T3 se repiten para asegurar que no ha habido interacciones no esperadas 
con A y B. Si surgen problemas en estas pruebas, esto significa probablemente que son debi- 
dos a las interacciones con el nuevo componente. Se localiza el origen del problema, simpli- 
ficando asi la localizacion y reparacion de defectos. El conjunto de pruebas T4 se ejecuta tam- 
bien sobre el sistema. Finalmente, el componente D se integra y se prueba utilizando las 
pruebas existentes y nuevas (T5). 

Cuando se planifica la integracion, tiene que decidirse el orden de integracion de los com- 
ponentes. En un proceso como XP, el cliente se implica en el proceso de desarrollo y decide 
que funcionalidad deberia incluirse en cada incremento del sistema. Por lo tanto, la integra- 
cion del sistema esta dirigida por las prioridades del cliente. En otras aproximaciones al des- 
arrollo, cuando se integran componentes comerciales y componentes especialmente desarro- 
llados, el cliente puede no estar implicado y el equipo de integracion decide sobre las 
prioridades de la integracion. 

En tales casos, una buena practica es integrar primero los componentes que implemen- 
tan las funcionalidades mas frecuentemente utilizadas. Esto significa que los componentes 
mas utilizados recibiran la mayoria de las pruebas. Por ejemplo, en el sistema de libreria 
LIBSYS, deberia comenzarse integrando la facilidad de busqueda para que, en un sistema 
minimo, los usuarios puedan buscar los documentos que necesitan. A continuacion, se de- 
beria anadir la funcionalidad para permitir a los usuarios descargar un documento, y des- 
pues agregar progresivamente los componentes que implementan otras caracteristicas del 
sistema. 

Por supuesto, la realidad es raramente tan simple como este modelo sugiere. La imple- 
mentacion de las caracteristicas puede estar repartida entre varios componentes. Para probar 
una nueva caracteristica, pueden tener que integrarse varios componentes diferentes. Las 
pruebas pueden revelar errores en las interacciones entre estos componentes individuales y 
otras partes del sistema. La reparacion de errores puede ser dificil debido a que un grupo de 
componentes que implementan la caracteristica del sistema pueden tener que cambiarse. Ade- 
mas, la integracion y prueba de un nuevo componente puede cambiar el patron de las inter- 
acciones de componentes ya probados. Se pueden manifestar errores que no habian apareci- 
do en las pruebas de la configuracion mas simple. 

Estos problemas significan que, cuando se integra un nuevo incremento, es importante vol- 
ver a ejecutar las pruebas para incrementos previos, asi como las nuevas pruebas requeridas 
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para verificar la nueva funcionalidad del sistema. Volver a ejecutar un conjunto existente de 
pruebas se denominapruebas de regresion. Si las pruebas de regresion ponen de manifiesto 
problemas, entonces tiene que comprobarse si estos son problemas en el incremento previo 
que el nuevo incremento ha puesto de manifiesto o si estos son debidos al incremento afladi- 
do de funcionalidad. 

Las pruebas de regresion son claramente un proceso caro y no resultan practicas sin algun 
soporte automatizado. En programacion extrema, tal y como se vio en el Capitulo 17, todas 
las pruebas se escriben como codigo ejecutable en donde la entrada de las pruebas y las sali- 
das esperadas son especificadas y automaticamente comprobadas. Cuando esto se usa en un 
marco de trabajo de pruebas automatizado como JUnit (Massol y Husted, 2003), esto signi- 
fica que las pruebas pueden volverse a ejecutar automaticamente. Es un principio basico de 
la programacion extrema que el conjunto completo de pruebas se ejecute siempre que se in- 
tegre nuevo codigo y que este nuevo codigo no sea aceptado hasta que todas las pruebas se 
ejecuten con exito. 



Las pruebas de entregas son el proceso de probar una entrega del sistema que sera distribui- 
da a los clientes. El principal objetivo de este proceso es incrementar la confianza del sumi- 
nistradoren que el sistema satisface sus requerimientos. Si es asi, este puede entregarse como 
un producto o ser entregado al cliente. Para demostrar que el sistema satisface sus requeri- 
mientos, tiene que mostrarse que este entrega la funcionalidad especificada, rendimiento y 
confiabilidad, y que no falla durante su uso normal. 

Las pruebas de entregas son normalmente un proceso de pruebas de caja negra en las que 
las pruebas se derivan a partir de la especificacion del sistema. El sistema se trata como una 
caja negra cuyo comportamiento solo puede ser determinado estudiando sus entradas y sus sa- 
lidas relacionadas. Otro nombre para esto es pruebas funcionales, debido a que al probador 
solo le interesa la funcionalidad y no la implementacion del software. 

La Figura 23.4 ilustra el modelo de un sistema que se admite en las pruebas de caja negra. 
El probador presenta las entradas al componente o al sistema y examina las correspondientes 
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salidas. Si las salidas no son las esperadas (es decir, si las salidas pertenecen al conjunto S.), 
entonces la prueba ha detectado un problema con el software. 

Cuando se prueban las entregas del sistema, deberia intentarse «romper» el software eli- 
giendo casos de prueba que pertenecen al conjunto E, en la Figura 23.4. Es decir, el objetivo 
deberia ser seleccionar entradas que tienen una alta probabilidad de generar fallos de ejecu- 
cion del sistema (salidas del conjunto S ). Se utiliza la experiencia previa de cuales son las 
pruebas de defectos que probablemente tendran exito y las guias de pruebas ayudaran a ele- 
gir la adecuada. 

Autores adecuada como Whittaker (Whittaker, 2002) han recogido su experiencia de prue- 
bas en un conjunto de guias que incrementan la probabilidad de que las pruebas de defectos 
tengan exito. Algunos ejemplos de estas guias son: 

1. Elegir entradas que fuerzan a que el sistema genere todos los mensajes de error. 

2. Disefiar entradas que hacen que los buferes de entrada se desborden. 

3. Repetir la misma entrada o series de entradas varias veces. 

4. Forzar a que se generen las salidas invalidas. 

5. Forzar los resultados de los calculos para que sean demasiado grandes o demasiado 
pequefios. 

Para validar que el sistema satisface los requerimientos, la mejor aproximacion a utilizar 
es la prueba basada en escenarios, en la que se idean varios escenarios y se desarrollan casos 
de prueba a partir de estos escenarios. Por ejemplo, el siguiente escenario podria describir 
como el sistema de libreria LIBSYS, tratado en capitulos anteriores, podria utilizarse: 

Una estudiante escocesa que estudia la Historia Americana tiene que escribir un tra- 
bajo sobre «la mentalldad sobre las fronteras en el Este Americano desde 1840 a 1880», 
Para hacer esto, necesita encontrar documentation de varias bibliotecas. Se registra 
en el sistem a LIBSYS y utiliza la facilidad de busqueda para ver sipuede acceder a los 
documentos originates de esa epoca. Descubre trabajos en varias bibliotecas universi- 
tarias deEstados Unidosy descarga copias de algunos de ellos. Sin embargo, para uno 
de ;os documentos, necesita tener confirmation de su Universidad de que ella es en ver- 
dad estudiante y de que el uso del documento es para fines no comerciales. La estu- 
diante entonces utiliza la facilidad de LLBSYS que le permite solicitar diclto permisoy 
registrar su petition. Si esta es aceptada, el documento podrd descargarse en el seni- 
dor de la biblioteca registrada y ser impreso. La estudiante recibe un mensaje de 
LIBSYS informdndole que recibird un mensaje de correo electrdnico cuando el docu- 
men to impreso este dispon ible para ser recogido. 

A partir de este escenario, es posible generar varias pruebas que pueden aplicarse a la en- 
trega propuesta de LIBSYS: 

1 . Probar el mecanismo de login usando logins correctos e incorrectos para comprobar 
que los usuarios validos son aceptados y que los invalidos son rechazados. 

2. Probar la facilidad de busqueda utilizando consultas con fuentes conocidas para com- 
probar que el mecanismo de busqueda realmente encuentra los documentos. 

3. Probar la facilidad de presentacion del sistema para comprobar que la informacion so- 
bre los documentos se visualiza adecuadamente. 

4. Probar el mecanismo para solicitar permisos para descargas. 

5. Probar la respuesta de correo electronico indicando que el documento descargado esta 
disponible. 
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Para cada una de estas pruebas, deberia disenarse un conjunto de pruebas que incluyan en- 
tradas validas e invalidas y que generen salidas validas e invalidas. Tambien deberian orga- 
nizarse pruebas basadas en escenarios para que los escenarios mas probables sean probados 
primero, y los escenarios inusuales o excepcionales sean probados mas tarde, de forma que 
el esfuerzo se centre en aquellas partes del sistema que reciben un mayor uso. 

Si se han utilizado casos de uso para describir los requerimientos del sistema, estos casos 
de uso y los diagramas de secuencia asociados pueden ser una base para las pruebas del sis- 
tema. Los casos de uso y los diagramas de secuencia pueden emplearse ambos durante la in- 
tegracion y pruebas de entregas. Para ilustrar esto, se utiliza un ejemplo del sistema de esta- 
cion meteorologica descrito en el Capitulo 14. 

La Figura 23.5 muestra la secuencia de operaciones en la estacion meteorologica cuando 
responde a una peticion para recoger datos del sistema de mapas. Puede utilizarse este dia- 
grama para identificar operaciones que seran probadas y ayudar al diseno de los casos de prue- 
ba para ejecutar las pruebas. Por lo tanto, la emision de una peticion de un informe dara lu- 
gar la ejecucion de la siguiente secuencia de metodos: 

CommsController:request-* Weatherstation: re port -»WeatherData:summarise 

El diagrama de secuencias tambien puede utilizarse para identificar entradas y salidas que 
tienen que crearse para las pruebas: 

1. Unaentradade una peticion de un informe deberia tenerun reconocimiento asociado 
y se deberia devolver en ultima instancia un informe a partir de la peticion. Durante 
las pruebas, se deberian crear datos resumidos que puedan utilizarse para comprobar 
que el informe esta organizado correctamente. 

2. Una peticion de entrada de un informe a Weatherstation provoca la generacion de 
un informe resumido. Se puede probar esto de forma aislada creando datos corres- 
pondientes al resumen que se ha preparado para las pruebas deCommsControllery 
comprobar que el objeto Weatherstation genera correctamente este resumen. 

3. Estos datos tambien se utilizan para probar el objeto Weatherstation. 
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Por supuesto, se ha simplificado el diagrama de secuencia en la Figura 23.5 para que no 
muestre las excepciones. Un escenario completo de pruebas deberia tener tambien estas en 
cuenta y asegurar que los objetos manejan correctamente las excepciones. 

23.1.3 Pruebas de rendlmlento 



Una vez que un sistema se ha integrado completamente, es posible probar las propiedades 
emergentes del sistema (vease el Capitulo 2) tales como rendimiento y fiabilidad. Las prue- 
bas de rendimiento tienen que disenarse para asegurar que el sistema pueda procesar su car- 
ga esperada. Esto normalmente implica planificar una serie de pruebas en las que la carga se 
va incrementando regularmente hasta que el rendimiento del sistema se hace inaceptable. 

Como sucede con otros tipos de pruebas, las pruebas de rendimiento se ocupan tanto de 
demostrar que el sistema satisface sus requerimientos como de descubrir problemas y defec- 
tos en el sistema. Para probar si los requerimientos de rendimiento son alcanzados, usted tie- 
ne que construir un perfil operacional. Un perfil operacional es un conjunto de pruebas que 
reflejan la combinacion real de trabajo que deberia ser manejada por el sistema. Por lo tanto, 
si el 90% de las transacciones en un sistema son de tipo A, un 5% de tipo B y el resto de ti- 
pos C, D y E, entonces usted tiene que disefiar el perfil operacional para que la amplia ma- 
yoria de las pruebas sean de tipo A. En caso contrario, no se tendra un test preciso del rendi- 
miento operacional del sistema. Se analizan los perfiles operacionales y su uso en las pruebas 
de fiabilidad en el Capitulo 24. 

Por supuesto, esta aproximacion no es necesariamente la mejor aproximacion para las 
pruebas de defectos. Tal y como se explica mas adelante, la experiencia ha demostrado que 
una forma efectiva de descubrir defectos es disenar pruebas alrededor de los limites del sis- 
tema. Las pruebas de rendimiento implican estresar el sistema (de ahi el nombre de pruebas 
de estres) realizando demandas que estan fuera de los limites del diseno del software. 

Por ejemplo, un sistema de procesamiento de transacciones puede disenarse para procesar 
hasta 300 transacciones por segundo; un sistema operativo puede disenarse para gestionar has- 
ta 1.000 terminales distintas. Las pruebas de estres van realizando pruebas acercandose a la 
maxima carga del diseno del sistema hasta que el sistema falla. Este tipo de pruebas tienen 
dos funciones: 

1 . Praeba el comportamiento de fallo de ejecucion del sistema. Pueden aparecer circuns- 
tancias a traves de una combinacion no esperada de eventos en donde la carga sobre el 
sistema supere la maxima carga anticipada. En estas circunstancias, es importante que 
un fallo de ej ecucion del sistema no provoque la corrupcion de los datos o perdidas in- 
esperadas de servicios de los usuarios. Las pruebas de estres verifican que las sobre- 
cargas en el sistema provocan «fallos ligeros» en lugar de colapsarlo bajo su carga. 

2. Sobrecargan el sistema y pueden provocar que se manifiesten defectos que normal- 
mente no sedan descubiertos. Aunque se puede argumentar que estos defectos es im- 
probable que causen fallos de funcionamiento en un uso normal, puede haber combi- 
naciones inusuales de circunstancias normales que las pruebas de estres pueden 
reproducir. 

Las pruebas de estres son particularmente relevantes para los sistemas distribuidos basa- 
dos en una red de procesadores. Estos sistemas exhiben a menudo una degradacion grave 
cuando son sobrecargados. La red se satura con datos de coordinacion que los diferentes pro- 
cesos deben intercambiar, de forma que los procesos son cada vez mas lentos a medida que 
esperan los datos requeridos de otros procesos. 
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23.2 Pruebas de componentes 

Las pruebas de componentes (a menudo denominadas pruebas de unidad) son el proceso de 
probar los componentes individuals en el sistema. Este es un proceso de pruebas de defec- 
tos, por lo que su objetivo es encontrar defectos en estos componentes. Tal y como se indico 
en la introduccion, para la mayoria de los sistemas, los desarrolladores de componentes son 
los responsables de las pruebas de componentes. 

Existen diferentes tipos de componentes que pueden probarse en esta etapa: 

1 . Funciones individuals o metodos dentro de un objeto. 

2. Clases de objetos que tienen varios atributos y metodos. 

3. Componentes compuestos formados por diferentes objetos o funciones. Estos com- 
ponentes compuestos tienen una interfaz definida que se utiliza para acceder a su fun- 
cionalidad. 

Las funciones o metodos individuales son el tipo mas simple de componente y sus prue- 
bas son un conjunto de llamadas u estas rutinas con diferentes parametros de entrada. Pueden 
utilizarse las aproximaciones para disefiar los casos de prueba, descritos en la seccion si- 
guiente, y para disefiar las pruebas de las funciones o metodos. 

Cuando se estan probando clases de objetos, deberian disefiar las pruebas para proporcio- 
nar cobertura para todas las caracteristicas del objeto. Por lo tanto, las pruebas de clases de 
objetos deberian incluir: 

1. Las pruebas aisladas de todas las operaciones asociadas con el objeto. 

2. La asignacion y consulta de todos los atributos asociados con el objeto. 

3. Ejecutarel objeto en todos sus posibles estados. Esto significa que deben simularse to- 
dos los eventos que provocan un cambio de estado en el objeto. 

Consideremos, por ejemplo, la estacion meteorologica del Capitulo 14 cuya interfaz se 
muestraen la Figura 23.6. Esta solo tiene un unico atributo, el cual es su identificador. Este 
es unaconstante que se asigna cuando la estacion meteorologica se instala. Por lo tanto, solo 
se necesita una prueba que compruebe si dicho atributo ha sido actualizado. Se necesita defi- 
nir casos de prueba para reportWeather, calibrate, test, startup y shutdown. En teoria, de- 
berian probarse los metodos de forma independiente, pero, en algunos casos, son necesarias 
algunas secuencias de pruebas. Por ejemplo, para probar shutdown se necesita haber ejecu- 
tado el metodo startup. 

Para probar los estados de la estacion meteorologica, se utiliza un modelo de estados tal 
y como se muestra en la Figura 14.14. Mediante este modelo, se pueden identificar se- 
cuencias de transiciones de estados que tienen que ser probadas y definir secuencias de 
eventos para forzar estas transiciones. En principio, deberia probarse cadaposible secuen- 



Figura 23.6 

La interfaz del objeto 
de la estacion 
meteorologica. 



Weatherstation 



identifier 

reportWeather 0 
calibrate (instruments) 
testO 

startup (instruments) 
shutdown (instruments) 



SB 



CAPITULO 23 • Pruebas del software 



cia de transicion de estados, aunque en lapractica esto puede suponerun coste demasiado 
elevado. Ejemplos de secuencias de estados que deberian probarse en la estacion meteoro- 
logica son los siguientes: 

Shutdown — • Waiting -* Shutdown 

Watting -* Calibrating -» Testing -» Transmitting - * Waiting 

Waiting - * Collecting - » Waiting -»• Summarising — Transmitting — Waiting 

Si se utilizaherencia, se hace mas dificil diseiiar las pruebas de clases de objetos. Siempre 
que una superclase proporcione operaciones que son heredadas por varias subclases, todas es- 
tas subclases deberian ser probadas con todas las operaciones heredadas. La razon de esto es 
que la operacion heredada puede hacer suposiciones sobre otras operaciones y atributos, que 
pueden haber cambiado cuando se han heredado. Del mismo modo, cuando una operacion de 
una superclase es sobrescrita, entonces la nueva operacion debe serprobada. 

La nocion de clases de equivalencia, expuesta en la Seccion 23.3.2, tambien puede apli- 
carse a clases de objetos. Las pruebas que pertenecen a la misma clase de equivalencia po- 
drian ser aquellas que utilizan los mismos atributos de los objetos. Por lo tanto, deberian iden- 
tificarse clases de equivalencia que inicializan, accedeny actualizan todos los atributos de las 
clases de objetos. 



23.2.1 Pruebas de Interfaces 



Muchos componentes en un sistema no son simples funciones u objetos, sino que son com- 
ponentes compuestos formados por varios objetos que interactuan. Tal y como se explico en 
el Capitulo 19, que trataba la ingenieria del software basada en componentes, se accede a las 
funcionalidades de estos componentes a traves de sus interfaces definidas. Entonces las prue- 
bas de estos componentes se ocupan principalmente de probar que la interfaz del componen- 
te se comportade acuerdo con su especificacion. 

La Figura 23.7 ilustra este proceso de pruebas de interfaces. Supongamos que los compo- 
nentes A, B y C se han integrado para formar un componente mas grande o subsistema. Los 
casos de prueba no se aplican a componentes individuates, sino a la interfaz del componente 
compuesto que se ha creado combinando estos componentes. 

Las pruebas de interfaces son particularmente importantes para el desarrollo orientado a 
objetos y basado en componentes. Los objetos y componentes se definen por sus interfaces y 
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pueden ser reutilizados en combinacion con otros componentes en sistemas diferentes. Los 
errores de interfaz en el componente compuesto no pueden detectarse probando los objetos 
individuates o componentes. Los errores en el componente compuesto pueden surgirdebido 
a interacciones entre sus partes. 

Existen diferentes tipos de interfaces entre los componentes del programa y, consecuente- 
mente, distintos tipos de errores de interfaces que pueden producirse: 

1. Interfaces de pardmetros. Son interfaces en las que los datos, o algunas veces refe- 
rencias a funciones, se pasan de un componente a otro en forma de parametros. 

2. Interfaces de memoria compartida. Son interfaces en las que un bloque de memoria 
se comparte entre los componentes. Los datos se colocan en la memoria por un sub- 
sistema y son recuperados desde aqui por otros subsistemas. 

3 . Interfaces procedwales. Son interfaces en las que un componente encapsula un con- 
junto de procedimientos que pueden ser llamados por otros componentes. Los objetos 
y los componentes reutilizables tienen esta forma de interfaz. 

4. Interfaces depaso de mensajes. Son interfaces en las que un componente solicita un 
servicio de otro componente mediante el paso de un mensaje. Un mensaje de retorno 
incluye los resultadosde laejecuciondel servicio. Algunos sistemas orientados a ob- 
jetos tienen esta forma de interfaz, asi como los sistemas cliente-servidor. 

Los errores de interfaces son una de las formas mas comunes de error en sistemas com- 
plejos (Lutz, 1993). Estos errores se clasifican en tres clases: 

1 . Mai uso de la interfaz. Un componente llama a otro componente y comete un error 
en la utilizacion de su interfaz. Este tipo de errores es particularmente comun con 
interfaces de parametros en donde los parametros pueden serde tipo erroneo, pue- 
den pasarse en el orden equivocado o puede pasarse un numero erroneo de parame- 
tros. 

2. No comprension de la interfaz. El componente que realiza la llamada no comprende 
la especificacion de la interfaz del componente al que llama, y hace suposiciones so- 
bre el comportamiento del componente invocado. El componente invocado no se com- 
porta como era de esperar y esto provoca un comportamiento inesperado en el com- 
ponente que hace la llamada. Por ejemplo, puede llamarse a una rutina de busqueda 
binaria con un vector no ordenado para realizar la busqueda. En este caso, la busque- 
da podria fallar. 

3 . Errores tetnporales. Se producen en sistemas de tiempo real que utilizan una memo- 
ria compartida o una interfaz de paso de mensajes. El productor de los datos y el con- 
sumidor de dichos datos pueden operar a diferentes velocidades. A menos que se ten- 
ga un cuidado particular en el diseno de la interfaz, el consumidor puede acceder a 
informacion no actualizada debido a que el productor de la informacion no ha actua- 
lizado la informacion de la interfaz compartida. 

Las pruebas para encontrar defectos en las interfaces son dificiles debido a que algunos de- 
fectos de las interfaces solo se pueden manifestar en condiciones inusuales. Por ejemplo, con- 
sideremos un objeto que implementa una cola con una estructura de datos de longitud fija. Un 
objeto que llama puede suponer que la cola esta implementada como una estructura de datos 
infinita y puede no comprobar el desbordamiento de la cola cuando se introduce un elemen- 
to. Esta condicion solo se puede detectar durante las pruebas disenando casos de prueba que 
fuerzan un desbordamiento de la cola y hacen que dicho desbordamiento no dane el compor- 
tamiento del objeto de alguna forma detectable. 
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Puede surgir un problema adicional debido a las interacciones entre los defectos en dis- 
tintos modulos u objetos. Los defectos en un objeto solo pueden ser detectados cuando algun 
otro objeto se comportade forma inesperada. Porejemplo, un objeto puede llamaraalgunotro 
objeto para recibir algun servicio y puede suponer que la respuesta es correcta. Si existe un 
malentendido sobre el valor calculado, el valor devuelto puede ser valido pero incorrecto. Esto 
solo se manifestara cuando algun calculo posterior sea erroneo. 

He aqui algunas guias generales para las pruebas de interfaz: 

1 . Examinar el codigo a probar y listar explicitamente cada llamada a un componente ex- 
terno. Disenarun conjunto de pruebas endonde los valores de losparametros para los 
componentes externos estan en los extremos de sus rangos. Es bastante probable que 
estos valores extremos revelen inconsistencias en la interfaz. 

2. En los lugares en los que se pasan punteros a traves de una interfaz, siempre probar la 
interfaz con parametros de punteros nulos. 

3. Cuando se llama a un componente a traves de una interfaz procedural, disenar 
pruebas que hagan que el componente falle. Realizar suposiciones de fallos de eje- 
cucion erroneas es una de las malas interpretaciones de especificacion mas comu- 
nes. 

4. Utilizar las pruebas de estres, tal y como se indico en la seccion previa, en los siste- 
mas de paso de mensajes. Disenar pruebas que generen muchos mas mensajes de los 
que probablemente ocurran en la practica. Los problemas temporales se detectan de 
esta manera. 

5. Cuando varios componentes interactuan a traves de memoria compartida, disenar 
pruebas que varian el orden en el que se activan estos componentes. Estas pruebas pue- 
den revelar suposiciones implicitas hechas por el programador sobre el orden en el que 
los datos compartidos son producidos y consumidos. 

Las tecnicas de validacion estaticas son amenudo mas rentables que las pruebas parades- 
cubrir errores de interfaz. Un lenguaje fuertemente tipado como Java permite que muchos 
errores de interfaz sean detectados por el compilador. Si se utiliza un lenguaje debilmente ti- 
pado, tal como C, un analizador estatico como LINT (vease el Capitulo 22) puede detectar 
errores de interfaz. Las inspecciones de programas se pueden centrar en las interfaces de los 
componentes y durante el proceso de inspeccion se pueden hacer preguntas sobre el compor- 
tamiento asumido de las interfaces. 



233 Diseho de casos de prueba 

El diseno de casos de prueba es una parte de las pruebas de componentes y sistemas en las 
que se disefian los casos de prueba (entradas y salidas esperadas) para probar el sistema. El 
objetivo del proceso de diseno de casos de prueba es crear un conjunto de casos de prueba que 
sean efectivos descubriendo defectos en los programas y muestren que el sistema satisface sus 
requerimientos. 

Para disenarun caso de prueba, se seleccionaunacaracteristicadel sistema o componen- 
te que se esta probando. A continuacion, se selecciona un conjunto de entradas que ejecutan 
dicha caracteristica, documenta las salidas esperadas o rangos de salida y, donde sea posi- 
ble, se disefia una prueba automatizada que prueba que las salidas reales y esperadas son las 
mismas. 
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Existen varias aproximaciones que pueden seguirse para disenar casos de prueba: 

1. Pruebas basadas en requerimientos, en donde los casos de prueba se disenan para 
probar los requerimientos del sistema. Esta aproximacion se utiliza principalmen- 
te en la etapa de pruebas del sistema, ya que los requerimientos del sistema nor- 
malmente se implementan por varios componentes. Para cada requerimiento, se 
identifica casos de prueba que puedan demostrar que el sistema satisface ese re- 
querimiento. 

2. Pruebas departiciones, en donde se identifican particiones de entraday saliday se di- 
senan pruebas para que el sistema ejecute entradas de todas las particiones y genere 
salidas en todas las particiones. Las particiones son grapos de datos que tienen carac- 
teristicas comunes, como todos los numeros negativos, todos los nombres con menos 
de 30 caracteres, todos los eventos provocados por la eleccion de opciones en un 
menu, y asi sucesivamente. 

3. Pruebas estructurales, en donde se utiliza el conocimiento de la estructura del pro- 
grama para disenar pruebas que ejecuten todas las partes del programa. Esencialmen- 
te, cuando se prueba un programa, deberia intentarse ejecutar cada sentencia al menos 
una vez. Las pruebas estructurales ayudan a identificar casos de prueba que pueden ha- 
cer esto posible. 

En general, cuando se diseflen casos de prueba, se deberia comenzar con las pruebas de 
mas alto nivel a partir de los requerimientos y a continuacion, de forma progresiva, anadir 
pruebas mas detalladas utilizando pruebas estructurales y pruebas de particiones. 

23.3.1 Pruebas basadas en requerimientos 

Un principio general de ingenieria de requerimientos, expuesto en el Capitulo 6, es que los 
requerimientos deberian poderprobarse. Es decir, los requerimientos deberian ser escritos de 
tal forma que se pueda disenar una prueba para que un observador pueda comprobar que los 
requerimientos se satisfacen. Las pruebas basadas en requerimientos, por lo tanto, son una 
aproximacion sistematica al diseno de casos de prueba en donde el usuario considera cada re- 
querimiento y deriva un conjunto de pruebas para cada uno de ellos. Las pruebas basadas en 
requerimientos son pruebas de validacion en lugarde pruebas de defectos — el usuario inten- 
ta demostrar que el sistema ha implementado sus requerimientos de forma adecuada. 

Porejemplo, consideremos los requerimientos para el sistema LIB SYS introducidos en el 
Capitulo 6. 

1. El usuario sera capaz de buscar en un conjunto inicial de bases de datos o bien selec- 
cionar un subconjunto de estas. 

2. El sistema proporcionara vistas apropiadas para que el usuario pueda leer los docu- 
mentos almacenados. 

3. Cada peticion deberia contenerun linico identificador (ORDER ID) que el usuario de- 
bera ser capaz de copiar en el area de peticiones de almacenamiento permanente. 

Posibles pruebas para el primero de estos requerimientos, suponiendo que se ha probado 
una funcion de busqueda, son: 

• Iniciar busquedas de usuario para elementos de los que se conoce que estan presentes y 
para elementos que se sabe quttno estan presentes, en las que el conjunto de bases de da- 
tos incluye una base de datos. 
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• Iniciarbusquedas de usuario para elementos de los que se sabe que estan presentes y para 
elementos de los que se sabe que no estan presentes, en las que el conjunto de bases de 
datos incluye dos base de datos. 

• Iniciarbusquedas de usuario para elementos de los que se sabe que estan presentes y para 
elementos de los que se sabe que no estan presentes, en las que el conjunto de bases de 
datos incluye mas de dos base de datos. 

• Seleccionaruna base de datos del conjunto de bases de datos e iniciarbusquedas de usua- 
rio para elementos que se sabe que estan presentes y para elementos de los que se sabe 
que no estan presentes. 

• Seleccionar mas de una base de datos del conjunto de bases de datos e iniciar busquedas 
de usuario para elementos de los que se sabe que estan presentes y para elementos de los 
que se sabe que no estan presentes. 

Se puede vera partirde esto que las pruebas de un requerimiento no significan escribir solo 
una unica prueba. Normalmente tienen que escribirse varias pruebas para asegurar que cubre 
por completo el requerimiento. 

Las pruebas para los otros requerimientos en el sistema LIBS YS pueden desarrollarse de 
la misma forma. Para el segundo requerimiento, deberian escribirse pruebas para que pudie- 
ran ser procesados por el sistema documentos entregados de todos los tipos y comprobar que 
se visualizan adecuadamente. El tercer requerimiento es mas sencillo. Paraprobarlo, se simula 
la emision de varios pedidos y entonces se comprueba que el identificadordel pedido estapre- 
sente en la confirmacion que recibe el usuario y que es unica en cada caso. 

23.3.2 Pruebas de partlclones 

Los datos de entrada y los resultados de salida de un programa normalmente se pueden agru- 
paren varias clases diferentes que tienen caracteristicas comunes tales como numeros positi- 
vos, numeros negativos y selecciones de menus. Los programas normalmente se comportan 
de una forma similar para todos los miembros de una clase. Es decir, si se prueba un progra- 
ma que realiza algiin calculo y requiere dos numeros positivos, entonces se esperaria que el 
programa se comportase de la misma forma para todos los numeros positivos. 

Debido a este comportamiento equivalente, estas clases se denominan a menudo particio- 
nes de equivalencia o dominios (Bezier, 1990). Una aproximacion sistematica al disefio de ca- 
sos de prueba se basa en identificar todas las particiones para un sistema o componente. Los 
casos de prueba se disenan para que las entradas o salidas pertenezcan a estas particiones. Las 
pruebas de particiones pueden utilizarse para disenar casos de prueba tanto para sistemas 
como para componentes. 

En la Figura 23.8, cada particion de equivalencia se muestra como una elipse. Las parti- 
ciones de equivalencia son conjuntos de datos en donde todos los miembros de los conjuntos 
deberian ser procesados de forma equivalente. Las particiones de equivalencia de salida son 
resultados del programa que tienen caracteristicas comunes, por lo que pueden considerarse 
como una clase diferente. Tambien se identifican particiones en donde las entradas estan fue- 
ra de otras particiones que se han elegido. Estas prueban si el programa maneja entradas in- 
validas de forma correcta. Las entradas validas e invalidas tambien forman particiones de 
equivalencia. 

Una vez que se ha identificado un conjunto de particiones, pueden elegirse casos de prue- 
ba de cada una de estas particiones. Una buena practica para la seleccion de casos de prueba 
es elegir casos de prueba en los limites de las particiones junto con casos de prueba cercanos 
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al punto medio de laparticion. La razonde esto es que los disenadores y programadores tien- 
den a considerar valores tipicos de entradas cuando desarrollan un sistema. Estos se prueban 
eligiendo el punto medio de la particion. Los valores limite son a menudo atipicos (por ejem- 
plo, el cero puede comportarse de forma diferente del resto de los numeros no negativos), por 
lo que los disenadores los pasan por alto. Los fallos de ejecucion de los programas a menudo 
ocurren cuando se procesan estos valores atipicos. 

Se identifican particiones usando la especificacion del programa o documentacion del 
usuario y, a partir de la propia experiencia, se predice que clases de valores de entrada es pro- 
bable que detecten errores. Por ejemplo, supongamos que una especificacion de un programa 
indica que el programa acepta de 4 a 8 entradas que son enteros de cinco digitos mayores de 
10.000. La Figura 23.9 muestra las particiones para esta situacion asi como los posibles va- 
lores de prueba de entrada. 
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Para ilustrar la derivacion de casos de praeba, se usa la especificacion de un componente 
de busqueda mostrado en la Figura 23.10. Este componente busca un elemento concreto (Key) 
en una secuencia de elementos. Devuelve la posicion de dicho elemento en la secuencia. Se 
ha especificado esto de forma abstracta definiendo precondiciones, que son ciertas antes de 
que se llame al componente, y postcondiciones, que son ciertas despues de su ejecucion. 

Las precondiciones indican que la rutina de busqueda solo funcionara con secuencias que 
no sean vacias. La postcondicion indica que la variable Found tomaun valor si el elemento 
buscado esta en la secuencia. La posicion del elemento buscado es el indice L. El valor del in- 
dice no esta definido si el elemento no esta en la secuencia. 

A partir de esta especificacion, pueden identificarse dos particiones de equivalencia: 

1. Entradas en las que el elemento a buscar es un miembro de la secuencia (Found = 
true). 

2. Entradas en las que el elemento a buscar no es un miembro de la secuencia (Found = 
false). 

Cuando se estan probando problemas con secuencias, vectores o listas, existen varias re- 
comendaciones que a menudo son utiles para disenar casos de prueba: 

1 . Probar el software con secuencias que tienen solo un valor. Los programadores pien- 
san de forma natural que las secuencias estan formadas por varios valores, y algunas 
veces consideran esta suposicion en sus programas. Como consecuencia, el programa 
puede no funcionar correctamente cuando se le presenta una secuencia con un unico 
valor. 

2. Utilizar varias secuencias de diferentes tamafios en distintas pruebas. Esto disminuye 
la probabilidad de que un programa con defectos produzca accidentalmente una sali- 
da correcta debido a alguna caracteristica ocasional en la entrada. 

3. Generar pruebas para acceder al primer elemento, al elemento central y al ultimo ele- 
mento de la secuencia. Esta aproximacion pone de manifiesto problemas en los limi- 
tes de la particion. 

A partir de estas recomendaciones, se pueden identificar dos particiones de equivalencia mas: 

1. La secuencia de entrada tiene un unico valor. 

2. El numero de elementos de la secuencia de entrada es mayor que I. 

A continuacion, se identifican particiones adicionales combinando estas particiones; por 
ejemplo, la particion en la que el numero de elementos en la secuencia es mayor que I y el ele- 



Figura 23.10 
Especificacion 
de una rutina 
de busqueda. 



i Search (Key : EL£M ; T: SEQ of ELEM ; 
Found : in out BOOLEAN; L in out ELEMJNDEX) ; 



- la secuencia tiene al menos un elemento 
TFIRST <- TLAST 



— el elemento se encuentra y es refetenciado por L 
( Found and T (L) « Key) 

— el elemento no esti en la secuencia 
(■at Found and 

Mt (exists i, TTIRST >>= i <= TLAST, T (i) = Key )) 
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Single value In sequence 

Single value Not in sequence 

More than 1 value First element in sequence 

More than 1 value Last element in sequence 

More than 1 value Middle element in sequence 

More than 1 value Not in sequence 




equivalencia para la 
rutina de busqueda. 



Figura 23.11 



Particiones de 



17 17 true, 1 

17 0 false, ?? 

17,29,21,23 17 true, 1 

41, 18, 9, 31, 30, 16, 45 45 true, 7 

17, 18, 21, 23, 29, 41, 38 23 true, 4 

21, 23, 29, 33, 38 25 false, V. 



mento no pertenece a la secuencia. La Figura 23.1 1 muestra las particiones que se han identi- 
ficado para probar el componente de busqueda. 

Un conjunto de posibles casos de prueba basados en estas particiones se muestran tambien 
en la Figura 23.11. Si el elemento a buscar no esta en la secuencia, el valor de L no esta defi- 
nido («??»}. La recomendacion de que deberian utilizarse diferentes secuencias de distintos 
tamanos se ha aplicado en estos casos de prueba. 

El conjunto de valores de entrada utilizados para probar la rutina de busqueda no es ex- 
haustive La rutina puede fallar si la secuencia de entrada incluye los elementos 1, 2, 3 y 4. 
Sin embargo, es razonable suponer que si la prueba falla al detectar defectos cuando uno de 
los miembros de la clase es procesado, ningun otro miembro de dicha clase identificara de- 
fectos. Por supuesto, los defectos todavia pueden existir. Algunas particiones de equivalencia 
pueden no haber sido identificadas, los errores pueden haberse cometido en la identificacion 
de las particiones de equivalencia o los datos de las pruebas pueden no haberse preparado co- 
rrectamente. 



Las pruebas estructurales (Figura 23. 12) son una aproximacion al diseno de casos de prueba 
en donde las pruebas se derivan a partir del conocimiento de la estructura e implementacion 
del software. Esta aproximacion se denomina a veces pruebas de «caja blanca», de «caja de 
cristal» o de «caja transparente» para distinguirlas de las pruebas de caja negra. 

La comprension del algoritmo utilizado en un componente puede ayudar a identificar par- 
ticiones adicionales y casos de prueba. Para ilustrar esto, se ha implementado la especifica- 



23.3.3 



Pruebas estructurales 



Datos de prueba 



T 



Pruebas 



Deriva en 



Figura 23.12 



Pruebas estructurales. 
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Elementos < Mid 




Elementos > Mid | 



Clases de f 
equivalencia de la J 
busqueda binaria. Punto medio 



cion de la rutina de busqueda (Figura 23.10) como una rutina de busqueda binaria (Figu- 
ra 23.14). Por supuesto, esta tiene precondiciones mas estrictas. La secuencia se implementa 
como un vector, este vector debe estar ordenado y el valor del llmite inferior del vector debe 
ser menor que el valor del limite superior. 

Examinando el codigo de la rutina de biisqueda, puede verse que la biisqueda binaria im- 
plica dividir el espacio de biisqueda en tres partes. Cada una de estas partes constituye una 
particion de equivalencia (Figura 23.13). A continuacion, se diseflan los casos de prueba en 
los que el elemento buscado se sitiia en los limites de cada una de estas particiones. 



Figura 23.14 



de la rutina de 
busqueda binaria. 



class BinSearch ( 

// Este es un encapsulamiento de una funddn de busqueda binaria que toma un 
// vector de objetos ordenados y una dave y devuelve un objeto con 2 atributos: 
// index - el valor del vector index 

// found - un valor booteano que indica si key esta en el vector. 

// Se devuelve un objeto puesto que en Java no es posible pasar tipos bisicos por 

// referenda a una fundon y por lo tanto devotver dos valores. 

// El valor de key es -1 si no se encuentra el elemento. 

public static void search ( int key, int fl etemAiray, Result r ) 
{ 

1 . int bottom — 0 ; 

2. int top « elemArray.length -1 ; 
int mid ; 

3. r.found - false ; 

4. rjndex - - 1 ; 

5. while ( bottom O top ) 
{ 

6. mid - (top + bottom) / 2 ; 

7. if (elemArray [mid] ~ key) 
( 

8. rjndex = mid ; 

9. r.found = true ; 

10. return ; 
J //if part 



( 

11. if (elemArray [mid] < key) 

12. bottom » mid + l ; 
else 

13. top- mid -l ; 
) 



mplementacidnJava , „ »/ /wh " e lo °P 

14. }// busqueda 



} //BinSearch 
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true, 1 
false, V 
true,l 
true, 7 
true, 4 
true, 3 
true, 4 
false, 77 



17 



O 



17,21,23,29 



17 



Figura 23.15 Casos 
de prueba para la 
rutina de busqueda. 



9, 16, 18, 30, 31, 41, 45 
17, 18, 21, 23, 29, 38, 41 
17, 18, 21, 23, 29, 33, 38 
12, 18,21,23,32 



45 
23 
21 
23 
25 



21, 23, 29, 33, 38 



Esto da lugar a un conjunto de casos de prueba revisados para la rutina de busqueda, tal y 
como se muestra en la Figura 23.15. Observe que se ha modificado el vector de entrada para 
que este ordenado de forma ascendente y se han anadido praebas adicionales en las que el ele- 
mento a buscar es adyacente a la posicion central del vector. 



Las pruebas de caminos son una estrategia de praebas estructurales cuyo objetivo es probar 
cada camino de ejecucion independiente en un componente o programa. Si cada camino in- 
dependiente, entonces todas las sentencias en el componente deben haberse ejecutado al me- 
nos una vez. Ademas, todas las sentencias condicionales compraeban para los casos verda- 
dero y falso. En un proceso de desarrollo orientado a objetos, pueden utilizarse las pruebas de 
caminos cuando se praeban los metodos asociados a los objetos. 

El numero de caminos en un programa es normalmente proporcional a su tamafio. Puesto 
que los modulos se integran en sistemas, no es factible utilizartecnicas de pruebas estructu- 
rales. Por lo tanto, las tecnicas de pruebas de caminos son principalmente utilizadas durante 
las pruebas de componentes. 

Las pruebas de caminos no prueban todas las posibles combinaciones de todos los cami- 
nos en el programa. Para cualquier componente distinto de un componente trivial sin bucles, 
este es un objetivo imposible. Existe un numero infinito de posibles combinaciones de cami- 
nos en los programas con bucles. Incluso cuando todas las sentencias del programa se han eje- 
cutado al menos una vez, los defectos del programa todavia pueden aparecer cuando se com- 
binan determinados caminos. 

El punto de partida de una prueba de caminos es un grafo de flujo del programa. Este es 
un modelo del esqueleto de todos los caminos en el programa. Un grafo de flujo consiste en 
nodos que representan decisiones y aristas que muestran el flujo de control. El grafo de flujo 
se constraye reemplazando las sentencias de control del programa por diagramas equivalen- 
tes. Si no hay sentencias goto en un programa, es un proceso sencillo derivar su grafo de flu- 
jo. Cada rama en una sentencia condicional (if-then-else o case) se muestra como un camino 
independiente. Una flecha que vuelve al nodo de la condicion denota un bucle. Se ha dibuja- 
do el grafo de nujo para el metodo de busqueda binaria en la Figura 23.16. Para establecer la 
correspondencia entre este y el programa de la Figura 23.14 de forma mas obvia, se ha mos- 
trado cada sentencia como un nodo separado en el que cada numero de nodo se corresponde 
con el mismo numero de linea en el programa. 

El objetivo de la prueba de caminos es asegurarque cada camino independiente en el progra- 
ma se ejecuta al menos una vez. Un camino independiente del programa es aquel que recorre al 
menos una nueva arista en el grafo de flujo. En terminos de programas, esto significa ejecutaruna 
o mas condiciones nuevas. Se deben ejecutar las ramas verdadera y falsa de todas las condiciones. 
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El grafo de flujo para el procedimiento de busqueda binaria se muestra en la Figura 23.16, 
en donde cada nodo representa una Hnea en el programa con una sentencia ejecutable. Por lo 
tanto, realizando trazas del flujo se puede verque los caminos en el grafo de flujo de busqueda 
binaria son: 

1,2.3,4,5, 6, 7, 8, 9, 10, 14 
1,2.3,4, 5, 14 

1,2, 3,4, 5, 6, 7, 11, 12, 5,... 
1,2, 3,4,6,7, 2, 11, 13,5,... 

Si se ejecutan todos estos caminos, podemos estar seguros de que cada sentencia en el me- 
todo ha sido ejecutada al menos una vez y que cada rama ha sido ejecutada para las condi- 
ciones verdadera y falsa. 

Se puede encontrar el numero de caminos independientes en un programa calculando la 
complejidad ciciomdtica (McCabe, 1976) del grafo de flujo delprograma. Para programas sin 
sentencias goto, el valor de la complejidad ciciomatica es uno mas que el numero de condi- 
ciones en el programa. Una condicion simple es una expresion logica sin conectores «and» u 



Figura 23.16 
Grafo de flujo para 
una rutina de 
busqueda binaria. 
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«or». Si el programa incluye condiciones compuestas, que son expresiones logicas con co- 
nectores «and» u «or», entonces cuenta ei numero de condiciones simples en las condiciones 
compuestas cuando calcula la complejidad ciclomatica. 

Por lo tanto, si hay seis sentencias if y un bucle while y todas las expresiones condiciona- 
les son simples, la complejidad ciclomatica es 8. Si una expresion condicional es una expre- 
sion compuesta tal como «if A and B or C». entonces esto se cuenta como tres condiciones 
simples. La complejidad ciclomatica, por lo tanto, es 10. La complejidad ciclomatica del al- 
goritmo de busqueda binaria (Figura 23.14) es 4 debido a que hay tres condiciones simples 
en las llneas 5. 7 y II. 

Despues de descubrir el numero de caminos independientes en el codigo calculando la 
complejidad ciclomatica, se necesita disenar casos de prueba para ejecutar cada uno de estos 
caminos. El numero minimo de casos de prueba necesarios para probar todos los caminos del 
programa es igual a la complejidad ciclomatica. 

El diseno de casos de prueba es sencillo en el caso de la rutina de busqueda binaria. Sin 
embargo, cuando los programas tienen una estructura de ramas compleja, puede ser dificil pre- 
decir como debera procesarse cualquier caso de prueba particular. En estos casos, para des- 
cubrir el perfil de ejecucion del programa, puede utilizarse un analizador dinamico de pro- 
gramas. 

Los analizadores dinamicos de programas son herramientas de pruebas que trabajan con- 
juntamente con los compiladores. Durante la compilacion, estos analizadores afiaden ins- 
trucciones adicionales al codigo generado. Estos cuentan el numero de veces que una sen- 
tencia ha sido ejecutada en un programa. Despues de que el programa se ha ejecutado, puede 
imprimirse un perfil de ejecucion. Este muestra que partes del programa han sido y no han 
sido ejecutadas utilizando casos de prueba particulares. Por lo tanto, este perfil de ejecucion 
revela secciones del programa no probadas. 

23.4 Automatizacion de las pruebas 

Las pruebas son una fase cara y laboriosa del proceso del software. Como consecuencia, las 
herramientas de prueba estaban entre las primeras herramientas de software a desarrollar. Ac- 
tualmente, estas herramientas ofrecen una serie de facilidades y su uso puede reducir signifi- 
cativamente los costes de las pruebas. 

Ya se hamostrado una aproximacion para la automatizacion de las pruebas (Mosley y Po- 
sey, 2002) en las que se utiliza un marco de trabajo de pruebas tal como JUnit (Massol y Hus- 
ted, 2003) para pruebas de regresion. JUnit es un conjunto de clases Java que el usuario ex- 
tiende para crear un entorno de pruebas automatizado. Cada prueba individual se implementa 
como un objeto y un ejecutador de pruebas ejecuta todas las pruebas. Las pruebas en si mis- 
mas deben escribirse de forma que indiquen si el sistema probado funciona como se esperaba. 

Un banco de pruebas del software es un conjunto integrado de herramientas para soportar 
el proceso de pruebas. Ademas de a los marcos de trabajo de pruebas que soportan la ejecu- 
cion automatica de las pruebas, un banco de trabajo puede incluir herramientas para simular 
otras partes del sistema y generar datos de prueba de dicho sistema. La Figura 23.17 muestra 
algunas de las herramientas que podrian incluirse en un banco de trabajo de pruebas de este 
tipo: 

1. Gestor de pruebas. Gestiona la ejecucion de las pruebas del programa. El gestor de 
pruebas mantiene un registro de los datos de las pruebas, resultados esperados y faci- 
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lidades del programa que han sido probadas. Los marcos de trabajo automatizados ta- 
les como JUnit son ejemplos de gestores de pruebas. 

2. Generador de datos de prueba. Genera datos de prueba para el programa a probar. 
Esto puede conseguirse seleccionando datos de una base de datos o utilizando patro- 
nes para generar datos aleatorios de forma correcta. 

3. Ordculo. Genera predicciones de resultados esperados de pruebas. Los oraculos pue- 
den ser versiones previas del programa o sistemas de prototipos. Las pruebas back-to- 
back (estudiadas en el Capitulo 17) implican ejecutar el oraculo y el programa a pro- 
bar en paralelo. Las diferencias entre sus salidas son resaltadas. 

4. Comparador de ficheros. Compara los resultados de las pruebas del programa con los 
resultados de pruebas previos e informa de las diferencias entre ellos. Los compara- 
dores se utilizan en pruebas de regresion en las que se comparan los resultados de eje- 
cutar diferentes versiones. Cuando se utilizan pruebas automatizadas, los comparado- 
res pueden ser llamados desde las mismas pruebas. 

5. Generador de informes. Proporciona la definicion de informes y facilidades de gene- 
racion para los resultados de las pruebas. 

6. Analizador dindmico. Anade codigo a un programa para contar el numero de veces que 
se ha ejecutado cada sentencia. Despues de las pruebas, se genera un perfil de ejecu- 
cion que muestra cuantas veces se ha ejecutado cada sentencia del programa. 

7. Simulador. Se pueden utilizar diferentes tipos de simuladores. Los simuladores de la 
maquina objetivo simulan la maquina sobre la que se ejecuta el programa. Los simu- 
ladores de interfaces de usuario son programas conducidos por scripts que simulan 
multiples interacciones de usuarios simultaneas. Utilizar simuladores para Entrada/Sa- 
lida implica que el comportamiento temporal de la secuencia de las transacciones es 
repetible. 

Cuando se utilizan para pruebas de grandes sistemas, las herramientas tienen que confi- 
gurarse y adaptarse para el sistema especifico que se esta probando. Por ejemplo: 
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1 . Pueden tenerque anadirse nuevas herramientas paraprobarcaracteristicas especificas 
de la aplicacion, y algunas herramientas existentes de prueba pueden no ser necesa- 
rias. 

2. Pueden tener que escribirse scripts para simuladores de interfaz de usuario y definir 
patrones para generadores de datos de pruebas. Los formatos de los informes tambien 
pueden tener que ser definidos. 

3. Pueden tener que prepararse manualmente los conjuntos de resultados esperados de 
las pruebas si no hay versiones previas de los programas disponibles que sirvan como 
oraculo. 

4. Pueden tener que escribirse comparadores de ficheros de proposito especial que in- 
cluyan conocimiento de la estructura de los resultados de las pruebas sobre ficheros. 

Normalmente, se necesita una cantidad significativa de esfuerzo y tiempo para crear un 
banco de trabajo de pruebas adecuado. Por lo tanto, los bancos de trabajo de pruebas com- 
pletes, tal y como se muestra en la Figura 23. 17, solo se utilizan cuando se desarrollan siste- 
mas grandes. Para estos sistemas, los costes totales de las pruebas pueden llegar al 50% del 
total de los costes de desarrollo, por lo que es rentable invertir en herramientas C A S E de alta 
calidad para soportar las pruebas. Sin embargo, debido a que diferentes tipos de sistemas re- 
quieren distintos tipos de soportes para las pruebas, puede que no esten disponibles herra- 
mientas de pruebas comerciales. Rankin (Rankin, 2002) analiza una situacion como esta en 
IB M y describe el diseno del sistema de soporte de pruebas que desarrollaron para un servi- 
dor de comercio electronico. 



PUNTOS CLAVE 

• Las pruebas solo pueden demostrar la presencia de errores en un programa. No pueden demostrar que no hay 
mas defectos. 

• Las pruebas de componentes son responsabilidad del desarrollador del componente. Un equipo indepen- 
diente de pruebas Neva a cabo normalmente las pruebas del sistema. 

• Las pruebas de integracidn son la actividad inicial de las pruebas del sistema en las que se prueban compo- 
nentes integrados para detectar defectos. Las pruebas de entregas estan relacionadas con ias pruebas de tas 
entregas al cliente y deberian validar que el sistema a entregar satisface sus requerimientos. 

• Cuando se prueban ios sistemas, deberia intentarse «romper» el sistema usando la experiencia y recomen- 
daciones para elegir tos tipos de casos de prueba que ban sido efectivos descubriendo defectos en otros sis- 
temas. 

• Laspruebasde interfaz intentan descubrir defectos en las j nterfaces de los componentes compuestos. Los de- 
fectos de las interfaces pueden ocurrir debido a errores cometidos en la lectura de la especif icacion, malen- 
tendidos en las especificaciones o errores o suposiciones temporales invalidas. 

• Las particiones de equivalencia son una forma de derivar casos de prueba. Dependen de encontrar particio- 
nes en los conjuntos de datos de entrada y salida y ejecutar el programa con valores de estas particiones. A 
menudo, el valor que sea mas probable que conduzca a una prueba con exito es un valor en los hmites de una 
partlclon. 
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• Las pruebas estructurales hacen referenda a analizar el programa para determinar caminos a traves de el y 
usar este ana lisis como ayuda parataseleccidndeloscasosdeprueba. 

La automatizacion de tas pruebas reduce los costes de las pruebas apoyando al proceso de pruebas con va- 
rias herramientas software. 



LECTURAS ADICIONALES N i * I I R IV1 I fVl I I I I B W I I I I 



How to Break Software: A Practical Guide to Testing. Este es un libro practico mas que teorico sobre las pruebas del 
software, en el que el autor presenta un conjunto de recomendaciones basadas en la experiencia sobre el diseno de 
las pruebas, que probablemente sean efectivas en el descubrimiento de defectos del sistema. (J. A. Whittaker, 2002, 
Add json-Wesley.) 

"Software Testing and Verification". Este numero especial del IBM Systems Journal contiene varios articulos sobre 
pruebas, incluyendo una buena revision, articulos sobre metricas de pruebas y automatizacion de pruebas. [IBM 
Systems Jounal, 41(1), enero de 2002.] 

Testing Object-oriented Systems: Models, Patterns and Tools. Este libro voluminoso proporciona un estudio com- 
pleto sobre las pruebas orientadas a objetos. Su volumen indica que no deberia ser el primer libro que se leyese so- 
bre pruebas orientadas a objetos (la mayona de los libros sobre desarrollo orientado a objetos tienen un capitulo 
de pruebas), pero claramente es el libro definitivo sobre pruebas orientadas a objetos. (R. V. Binder, 1999, Addison- 
Wesley.) 

• How to design practical test cases*. Un articulo sobre como disehar casos de prueba por un autor de una compa- 
ma japonesa que tiene fama de entregar software con muy pocos defectos. JT. Yamaura, IEEE Software, 15(6), No- 
viembre 1998.I 



23.1 Explique por que las pruebas solo pueden detectar la presencia de errores, no su ausencia. 

232 Compare una integracion y pruebas ascendente y descendente comentando sus ventajas y desventajas 
para pruebas arquitectonicas, para mostrar una version del sistema a los usuarios y para la imptementa- 
cion practica y observacion de las pruebas. Explique por que la integracion de la mayona de los sistemas 
grandes, en la practica, tiene que usar una mezcla de aproximaciones ascendentes y descendentes. 

23.3 iQue son tas pruebas de regresion? Explique como el uso de pruebas automaticas y un marco de trabajo 
de pruebas tal como JUnit simplifica las pruebas de regresion. 

23.4 Escriba un escenario que pod ri a utilizarsecomo base para derivar pruebas del sistema deestacion meteo- 
rologica que fue utilizado como ejemplo en el Capitulo 14. 

23.5 Utilizando el diagrama de secuencia de la Figura 8.14 como escenario, proponga pruebas para la peticion 
de elementos elect ronicosenel sistema LIBSYS. 
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23.6 ^Cuales son los problemas que se plantean al desarrollar pruebas de rendimiento para un sistema de base 
de datos distribuida tal como el sistema LIBSYS? 

23.7 Explique por que las pruebas de interfaz son necesarias incluso cuando los componentes individuales han 
sido validados extensamente a traves de las pruebas de componentes e inspecciones de programas. 

23.8 Utilizando la aproximacion presentada aquipara pruebas de objetos, disefie casos de prueba para probar 
los estados del horno mkroondas cuyo modelo de estados se define en la Figura 8.5. 

23.9 Se le ha solicitado que pruebe un metodo denominado catWhiteSpace en un objeto Paragraph que, den- 
tro de un parrafo, reemplace secuencias de caracteres en bianco con un unico caracteren bianco. Identifi- 
que particiones de pruebas para este ejemplo y derive un conjunto de pruebas para el metodo catWhi- 
teSpace. 

23.10 Indique tres situaciones en las que las pruebas de todos los caminos independientes en un programa pue- 
den no detectar errores en el programa. 
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Objetivos 

El objetivo de este capitulo es estudiar las tecnicas de verificacion 
y validacion utilizadas en el desarrollo de sistemas criticos. 
Cuando haya leido este capitulo : 

• comprendera como puede medirse la fiabilidad del software y 
como los modelos de crecimiento de fiabilidad pueden 
utilizarse para predecir cuando sera alcanzado un nivel 
requerido de fiabilidad; 

• comprendera los principios de los argumentos de seguridad y 
como estos pueden utilizarse junto con otros metodos de V & V 
para garantizar la seguridad de un sistema; 

• comprendera los problemas de garantizar la proteccion de un 
sistema; 

• habra sido introducido en casos de seguridad que presentan 
argumentos y evidencias de la seguridad de un sistema. 

Contenidos 

24.1 Validacion de la fiabilidad 

24.2 Garantia de la seguridad 

24.3 Valoracion de la proteccion 

24.4 Argumentos de confiabilidad y de seguridad 
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Obviamente, la verificacion y validacion de un sistema critico tiene mucho en comun con la 
validacion de cualquier otro sistema. Los procesos de V & V deberian demostrarque el sis- 
tema satisface su especificacion y que los servicios del sistema y su comportamiento estan 
acordes con los requerimientos del cliente. Sin embargo, para sistemas criticos, en los que se 
requiere un alto nivel de confiabilidad, son necesarias praebas y analisis adicionalesparapro- 
porcionar la evidencia de que el sistema es confiable. Existen dos razones de por que esto es 
necesario: 

1. Costes defallos de ejecucidn. Los costes y las consecuencias de los fallos de eje- 
cucion de los sistemas criticos son potencial mente mucho mas grandes que para los 
sistemas no criticos. Pueden reducirse los riesgos de los fallos del sistema invir- 
tiendo mas en verificacion y validacion del sistema. Normalmente es mas econo- 
mico encontrar y eliminar defectos antes de que el sistema sea entregado que pa- 
gar por los consecuentes costes de accidentes o de un mal funcionamiento de los 
servicios del sistema. 

2. Validacion de los atributos de confiabilidad. Puede tenerse que hacer una demostra- 
cion formal a los clientes de que el sistema satisface sus requerimientos especificados 
de confiabilidad (disponibilidad, fiabilidad, seguridad y proteccion). Para evaluares- 
tas caracteristicas de confiabilidad se requieren actividades especificas de V & V ex- 
plicadas mas adelante en este capitulo. En algunos casos, los reguladores externos, ta- 
les como autoridades de aviacion nacionales, pueden tener que certificar que el sistema 
es seguro antes de que este sea desplegado. Para obtener esta certificacion, pueden te- 
nerse que disenar y llevar a cabo procedimientos de V & V especiales que recogen la 
evidencia sobre la confiabilidad del sistema. 

Por estas razones, los costes de V & V para sistemas criticos son generalmente mucho ma- 
yores que para otras clases de sistemas. Es normal que el proceso de V & V consuma mas del 
50% de los costes totales de desarrollo para sistemas de software criticos. Por supuesto, este 
coste estajustificado si se quiere evitar un fallo de ejecucion del sistema que sea caro. Por 
ejemplo, en 1996 un sistema de software de mision critica en el cohete Ariane 5 fallo y se des- 
truyeron varios satelites. Lasperdidas secifraron encientosde millonesde dolares. La sub- 
siguiente investigacion descubrio que las deficiencias en el sistema de V & V fueron parcial- 
mente responsables de este fallo. 

Aunque el proceso de validacion de sistemas criticos se centra principalmente en la vali- 
dacion del sistema, otras validaciones relacionadas deberian verificar que los procesos de des- 
arrollo del sistema definidos han sido seguidos. Tal y como se explica en los Capitulos 27 y 
28, la calidad del sistema se ve afectada por la calidad de los procesos utilizados para des- 
arrollar el sistema. En resumen, buenos procesos conducen a buenos sistemas. Por lo tanto, 
para producir sistemas confiables, es necesario asegurarse de que se ha seguido un proceso de 
desarrollo robusto. 

Esta garantia del proceso es una parte inherente de los estandares ISO 9000 para la ges- 
tion de la calidad, descritos brevemente en el Capitulo 27. Estos estandares requieren do- 
cumentar los procesos que se utilizan y las actividades asociadas para asegurar que se han 
seguido estos procesos. Esto normalmente requiere la generacion de registros del proceso, 
tales como formularios firmados, que certifiquen la finalizacion de las actividades del pro- 
ceso y comprobaciones de calidad del producto. Los estandares ISO 9000 especifican que 
salidas tangibles del proceso deberian producirse y quien es el responsable de producirlas. 
En la Seccion 24.2.2 se proporciona un ejemplo de un registro para un proceso de analisis 
de contingencias. 
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Tal y como se explico en el Capitulo 9. se han desarrollado varias metricas para especificar 
los requerimientos de fiabilidad de un sistema. Para validar que el sistema satisface estos re- 
querimientos, tiene que medirse la fiabilidad del sistema tal y como lo ve un usuario tipico 
del mismo. 

El proceso de medir la fiabilidad de un sistema se ilustra en la Figura 24.1. Este proceso 
comprende cuatro etapas: 

1 . Se comienza estudiando los sistemas existentes del mismo tipo para establecer un per- 
fil operacional. Un perfil operacional identifica las clases de entradas al sistema y la 
probabilidad de que estas entradas ocurran en un uso normal. 

2. A continuacion, se construye un conjunto de datos de prueba que reflejan el perfil ope- 
racional. Esto significaque se crean datos de prueba con la mismadistribucionde pro- 
babilidad que los datos de prueba para los sistemas que se han estudiado. Normal- 
mente, se utiliza un generador de datos de prueba para soportar este proceso. 

3. Se prueba el sistema utilizando estos datos y se contabiliza el numero y tipo de fallos 
que ocurren. Los instantes en los que ocurren estos fallos tambien son registrados. Tal 
y como se indico en el Capitulo 9, las unidades de tiempo que se elijan deberian ser 
adecuadas para la metrica de fiabilidad utilizada. 

4. Despues de que se ha observado un numero de fallos significativos estadisticamente, 
se puede calcular la fiabilidad del software y obtener el valor adecuado de la metrica 
de fiabilidad. 

Esta aproximacion se denomina a menudopruebas estadisticas. El objetivo de las pruebas 
estadisticas es evaluar la fiabilidad del sistema. Esto contrasta con la prueba de defectos, des- 
crita en el Capitulo 23, en la que el objetivo es descubrir defectos del sistema. Prowell y otros 
(Prowell etah, 1999) proporcionan una buena descripcion de las pruebas estadisticas en su li- 
bra sobre ingenieriadel software de Sala Limpia. 

Esta aproximacion para la medicion de la fiabilidad es atractiva conceptualmente, pero no 
es facil de aplicar en la practica. Las principales dificultades que presenta son: 

1 . ;ncertidumbre del perfil operacional. Los perfiles operacionales basados en la expe- 
riencia con otros sistemas pueden no ser un reflejo exacto del uso real del sistema. 

2. Costes elevados degeneration de datos de prueba. Puede ser muy caro generar el gran 
volumen de datos requeridos en un perfil operacional a menos que el proceso pueda 
ser automatizado completamente. 

3 . jncertidumbre estadistica cuando se especifica una fiabilidad alta. Se tiene que pro- 
vocar un numero de fallos significativo estadisticamente para permitir mediciones de 
fiabilidad exactas. Cuando el software ya es fiable, ocurren relativamente pocos fallos 
y es dificil provocar nuevos fallos. 

Desarrollar un perfil operacional preciso es ciertamente posible para algunos tipos de sis- 
temas, como los sistemas de telecomunicaciones, que tienen un patron de uso estandarizado. 
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Sin embargo, para otros tipos de sistemas, hay muchos usuarios diferentes que tienen su pro- 
pia forma de utilizar el sistema. Tal y como se explico en el Capitulo 3, distintos usuarios pue- 
den obtener impresiones de fiabilidad completamente diferentes debido a que utilizan el sis- 
tema de forma distinta. 

Con diferencia, la mejor forma de generar los grandes conjuntos de datos requeridos para 
la medicion de la fiabilidad es utilizar un generador de datos de prueba que pueda generar au- 
tomaticamente las entradas correspondientes al perfil operacional. Sin embargo, normalmen- 
te no es posible automatizar la produccion de todos los datos de prueba para sistemas inter- 
activos debido a que las entradas son a menudo una respuesta a las salidas del sistema. Los 
conjuntos de datos para estos sistemas tienen que generarse manualmente, con sus corres- j 
pondientes costes mas elevados. Incluso en los casos en los que es posible automatizar com- 
pletamente el proceso, escribir los comandos para el generador de los datos de prueba puede 
llevaruna cantidad de tiempo significativa. 

La incertidumbre estadistica es un problema general en la medicion de la fiabilidad de un 
sistema. Para llevar acabo prediccionesprecisas de fiabilidad, se necesita haceralgo masque 
simplemente provocar un unico fallo de ejecucion del sistema. Tiene que generarse un numero 
razonablemente grande y significativo estadisticamente para tener la seguridad de que su me- 
dicion de la fiabilidad es precisa. Cuanto mas se disminuya el numero de defectos en un sis- 
tema, mas dificil resultara medir la efectividad de las tecnicas de minimizacion de defectos. 
Si se especifican niveles muy altos de fiabilidad, a menudo no es practico generar suficientes 
fallos del sistema para comprobar estas especificaciones. 

24.1.1 Perflles operaclonales 

El perfil operacional del software refleja como se utilizara este en la practica. Consiste en 
la especificacion de clases de entradas y la probabilidad de su ocurrencia. Cuando un nue- 
vo sistema software reemplaza a un sistema existente manual o automatizado, es razona- 
blemente facil evaluar el patron de uso probable del nuevo software. Este deberia corres- 
ponderse con el uso del sistema existente, con algunas adiciones para las nuevas 
funcionalidades que (presumiblemente) se incluyen en el nuevo software. Por ejemplo, 
puede especificarse un perfil operacional para sistemas de centralitas de telecomunicacio- 
nes debido a que las companias de telecomunicaciones conocen los patrones de llamadas 
que estos sistemas tienen que manejar. 

Tipicamente, el perfil operacional es tal que las entradas que tienen la probabilidad mas 
alta de ser generadas se concentran en un pequeno numero de clases, tal y como se muestra a 
la izquierda de la Figura 24.2. Hay un numero extremadamente grande de clases en las que 
las entradas son altamente improbables, pero no imposibles. Estas se muestran a la derecha 
de la Figura 24.2. Los puntos suspensivos (...) significan que existen mas de estas entradas in- 
usuales que no se muestran. 

Musa (Musa, 1993; Musa, 1998) sugiere recomendaciones para el desarrollo de perflles 
operacionales. Este autortrabajo en ingenieriade sistemas de telecomunicaciones, y exis- 
te una gran tradicion en la recoleccion de datos de uso en este dominio. Como consecuen- 
cia, el proceso de desarrollo de perflles operacionales es relativamente sencillo. Paraun sis- 
tema que requiere alrededorde 15 personas-ano de esfuerzo de desarrollo, se desarrollo un 
perfil operacional de alrededor de 1 persona-mes. En otros casos, el esfuerzo de la genera- 
cion del perfil operacional fue mayor (2-3 personas-ano), pero el coste disminuyo a lo lar- 
go de varias entregas del sistema. Musa se dio cuenta de que su compania (una compania 
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de telecomunicaciones) tuvo un beneficio de al menos diez veces la inversion requerida para 
desarrollar un perfil operacional. 

Sin embargo, cuando un sistema software es nuevo e innovador, es dificil anticipar como 
sera utilizado y, por lo tanto, generar un perfil operacional preciso. Muchos usuarios diferen- 
tes con distintas expectativas, conocimientos y experiencia pueden usar el nuevo sistema. No 
existen bases de datos historicas de uso. Estos usuarios pueden hacer uso de los sistemas en 
formas que no han sido anticipadas por los desarrolladores del sistema. 

El problema se complica mas debido a que los perfiles operacionales pueden cambiar con- 
forme se utiliza el sistema. A medida que los usuarios comprenden el nuevo sistema y confi- 
anmas en el, amenudo lo utilizande forma mas sofisticada. Debido a estas dificultades, Ham- 
let (Hamlet, 1992) sugiere que a veces es imposible desarrollar un perfil operacional fiable. 
Si el usuario no esta seguro de que su perfil operacional es correcto, entonces no puede con- 
fiar en la exactitud de sus mediciones de fiabilidad. 



24.1.2 Prediction de la fiabilidad 

Durante la validacion del software, los gestores tienen que dedicar esfuerzo a las pruebas del 
sistema. Puesto que el proceso de pruebas es muy caro, es importante dejar de probar tan pron- 
to como sea posible y no «sobreprobar» el sistema. Las pruebas pueden detenerse cuando se 
alcance el nivel requerido de fiabilidad del sistema. Algunas veces, por supuesto, las predic- 
ciones de fiabilidad pueden revelar que el nivel requerido de fiabilidad nunca conseguira. En 
este caso, el gestor debe tomar decisiones dificiles sobre la reescritura de parte del software 
o renegociar el contrato del sistema. 

Un modelo de crecimiento de fiabilidad es un modelo de como cambia la fiabilidad del sis- 
tema a lo largo del tiempo durante el proceso de pruebas. A medida que se descubren los fa- 
llos del sistema, los defectos subyacentes que provocan estos fallos son reparados para que la 
fiabilidad del sistema mejore durante las pruebas y depuracion. Para predecir la fiabilidad, el 
modelo conceptual de crecimiento de la fiabilidad debe ser traducido a un modelo matemati- 
co. Aqui no se entra en este nivel de detalle, sino que simplemente se plantea el principio del 
crecimiento de la fiabilidad. 

Existen varios modelos de crecimiento de la fiabilidad que han sido derivados de experi- 
mentos de fiabilidad en varios dominios de aplicacion diferentes. Tal y como Kan (Kan, 
2003) pone de manifiesto, la mayoria de estos modelos son exponenciales, en los que la fia- 
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bilidad crece rapidamente y los defectos son descubiertos y eliminados (vease la Figura 24.5}. 
A continuacion, el crecimiento se estabiliza y alcanza un nivel a medidaque cada vez menos 
defectos son descubiertos y eliminados en posteriores etapas de pruebas. 

El modelo mas simple que ilustra el concepto de crecimiento de la fiabilidad es un mode- 
lo de funciones por pasos (Jelinski y Moranda, 1972). La fiabilidad crece de forma constan- 
te cada vez que un defecto (o un conjunto de defectos) es descubierto y reparado (Figu- 
ra 24.3) y una nueva version del software es creada. Este modelo supone que las reparaciones 
del software se implementan siempre correctamente, de forma que el numero de defectos del 
software y fallos asociados decrece en cada nueva version del sistema. A medida que tienen 
lugar las reparaciones, la tasa de ocurrenciade fallos del software (ROCOF) deberia por tan- 
to reducirse, tal y como se muestra en la Figura 24.3. Note que los periodos de tiempo sobre 
el eje horizontal reflejan el tiempo entre entregas del sistema para pruebas, de forma que nor- 
malmente tienen longitudes diferentes. 

En la practica, sin embargo, los defectos del software no siempre se reparan durante la de- 
puracion, y cuando se cambia un programa, a menudo se introducen nuevos defectos. La pro- 
babilidad de ocurrencia de estos defectos puede ser mayor que la probabilidad de ocurrencia 
del defecto que ha sido reparado. Por lo tanto, la fiabilidad del sistema a veces puede empeo- 
rar en una nueva entrega en lugar de mejorar. 

El modelo simple de crecimiento de la fiabilidad de pasos iguales tambien supone que to- 
dos los defectos contribuyen de igual forma a la fiabilidad y que cada reparacion de los de- 
fectos contribuye en la misma medida al crecimiento de la fiabilidad. Sin embargo, no todos 
los defectos son igualmente probables. Reparar los defectos mas comunes contribuye mas al 
crecimiento de la fiabilidad que reparar defectos que solo ocurren de forma ocasional. Al 
usuario tambien le gustaria encontrar estos defectos probables cada vez en el proceso de 
pruebas, de forma que la fiabilidad puede crecer mas que en etapas posteriores, en las que los 
defectos menos probables son descubiertos. 

Modelos posteriores, como los sugeridos por Littlewood y Verrall (Littlewood y Verrall. 
1973) tienen en cuenta estos problemas introduciendo un elemento aleatorio en la mejora del 
crecimiento de la fiabilidad conseguida por una reparacion del software. Asi, cada reparacion 
no da como resultado una cantidad igual de la mejora de la fiabilidad, sino que varia depen- 
diendo de laperturbacionaleatoria (Figura 24.4). 
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El modelo de Littlewood y Verrall permite un crecimiento de la fiabilidad negativo cuan- 
do una reparacion del software introduce errores adicionales. Tambien modela el hecho de que 
a medida que los defectos son reparados, el promedio de mejora en cuanto a fiabilidad por re- 
paracion disminuye. La razon de esto es que los defectos mas probables probablemente sean 
descubiertos pronto en el proceso de praebas. La reparacion de estos defectos contribuye mas 
al crecimiento de la fiabilidad. 

Los modelos anteriores son modelos discretos que reflejan el crecimiento de la fiabilidad de 
forma incremental. Cuando se entrega para las pruebas una nueva version del software con de- 
fectos reparados deberia haber una menor tasa de ocurrencia de fallos que en la version previa. 
Sin embargo, para predecir la fiabilidad que debera alcanzarse despues de una determinada can- 
tidad de pruebas, son necesarios modelos matematicos continuos. Se han propuesto y compa- 
rado muchos modelos, derivados de diferentes dominios de aplicacion (Littlewood, 1990). 

De forma sencilla, puede predecirse la fiabilidad comparando los datos medidos de la fia- 
bilidad con un modelo de fiabilidad conocido. A continuacion, se extrapola el modelo al ni- 
vel requerido de fiabilidad y se observa cuando se alcanzara dicho nivel (Figura 24.5). Por lo 
tanto, las pruebas y la depuracion deben continuar hasta ese momento. 
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La prediccion de la fiabilidad del sistema a partir de un modelo de crecimiento de fiabili- 
dad tiene dos ventajas principales: 

1. Planificacion de las pruebas. Dado el calendario actual de pruebas, puede predecirse 
cuando se completaran las pruebas. Si el final de las pruebas tiene lugar despues de 
la fecha planificada de entrega del sistema, entonces puede tenerse que desplegar re- 
cursos adicionales para probar y depurar, y asi acelerar la tasa de crecimiento de fia- 
bilidad. 

2. Negociaciones con ei cliente. Algunas veces el modelo de fiabilidad muestra que el 
crecimiento de la fiabilidad es muy lento y que se requiere una cantidad de esfuerzo 
de pruebas desproporcionada para obtener un beneficio relativamente pequeno. Pue- 
de merecer la pena renegociar los requerimientos de fiabilidad con el cliente. De for- 
ma alternativa, puede ocurrir que el modelo prediga que la fiabilidad requerida pro- 
bablemente nunca sera alcanzada. En este caso, se tendran que renegociar con el 
cliente los requerimientos de la fiabilidad del sistema. 

Se ha simplificado aqui el modelado del crecimiento de la fiabilidad para proporcionarle 
un conocimiento basico del concepto. Si se desea utilizar estos modelos, se tiene que profun- 
dizarmas y comprender las matematicas subyacentes a estos modelos y sus problemas prac- 
ticos. Littlewood y Musa (Littlewood, 1990; Abdel-Ghaly et ai, 1986; Musa, 1998) han es- 
crito extensamente sobre los modelos de crecimiento de la fiabilidad y Kan (Kan, 2003) tiene 
un excelente resumen en su libro. Varios autores han descrito su experiencia practica en el uso 
de los modelos de crecimiento de fiabilidad (Ehrlich et al., 1993; Schneidewind y Keller, 
1992; Sheldon etal, 1992). 

24.2 Garantia de la seguridad 

El proceso de la garantia de la seguridad y la validacion de la fiabilidad tienen objetivos di- 
ferentes. Se puede especificar la fiabilidad de forma cuantitativa utilizando alguna metrica y 
a continuacion medir la fiabilidad del sistema completo. Dentro de los limites del proceso de 
medicion, se sabe si haalcanzado el nivel requerido de fiabilidad. La seguridad, sin embargo, 
no puede especificarse de forma cuantitativa y, por lo tanto, no puede medirse cuando se prue- 
ba un sistema. 

Por lo tanto, la garantia de la seguridad esta relacionada con establecer un nivel de con- 
fianza en el sistema que podria variar desde «muy bajo» hasta «muy alto». Esta es una cues- 
tion de juicio profesional basado en evidencias sobre el sistema, su entorno y su proceso de 
desarrollo. En muchos casos, esta confianza esta basada parcialmente en la experiencia de la 
organizacion que desarrolla el sistema. Si una compania ha desarrollado previamente varios 
sistemas de control que funcionan de forma segura, entonces es razonable suponer que esta 
continuara desarrollando sistemas seguros de este tipo. 

Sin embargo, dicha evaluacion debe contrastarse con evidencias tangibles a partir del di- 
seno del sistema, los resultados de la V & V del sistema, y los procesos de desarrollo del sis- 
tema que se han utilizado. Para algunos sistemas, esta evidencia tangible se consigue en un 
caso de seguridad (vease la Seccion 24.4) que permite a un regulador externo llegar a una con- 
clusion justificada de la confianza del desarrollador en la seguridad del sistema. 

Los procesos de V & V para sistemas de seguridad criticos tienen mucho en comun con 
los procesos comparables de cualquier otro sistema con altos requerimientos de fiabilidad. 
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Se deben realizar unas pruebas generales para descubrir el mayor numero posible de de- 
fectos, y cuando resulte apropiado, pueden utilizarse pruebas estadisticas para evaluar la 
fiabilidad del sistema. Sin embargo, debido a las tasas de fallos ultrabajas requeridas en mi- 
chos sistemas de seguridad criticos, las pruebas estadisticas no siempre proporcionan una 
estimacion cuantitativa de la fiabilidad del sistema. Las pruebas simplemente proporcionan 
alguna evidencia, que se usa con alguna otra evidencia como los resultados de las revisio- 
nes y comprobaciones estaticas (vease el Capitulo 22), para hacer un juicio sobre la segu- 
ridad del sistema. 

Las revisiones extensas son esenciales durante un proceso de desarrollo orientado a la se- 
guridad, para exponer el software a la gente, que lo vera desde diferentes perspectivas. Par- 
nas y otros (Pamas etal., 1990) sugieren cinco tipos de revisiones que deberian ser obligato- 
rias para los sistemas de seguridad criticos: 

1 . revision para corregir la funcion que se pretende; 

2. revision para una estructura comprensible y mantenible; 

3. revision para verificar que el algoritmoy el disenode las estructuras de datos soncon- 
sistentes con el comportamiento especificado; 

4. revision de la consistencia del codigo y del disefio del algoritmo y de las estructuras 
de datos; 

5. revision de la adecuacion de los casos de prueba del sistema. 

Una suposicion que subyace al trabajo en la seguridad de los sistemas es que el numero de 
defectos en el sistema que puede dar lugar a contingencias de seguridad criticas es significa- 
tivamente menor que el numero total de defectos que pueden existir en el sistema. La garan- 
tia de la seguridad puede concentrarse en estos defectos con potencial de contingencia. Si pue- 
de demostrarse que estos defectos pueden no ocurrir o, si lo hacen, la contingencia asociada 
no provocara un accidente, entonces el sistema es seguro. Esta es la base de los argumentos 
de seguridad que se exponen en la siguiente seccion. 

24.2.1 Argumentos de seguridad 

Las demostraciones de correccion de los programas, tal y como se se explico en el Capitulo 
22, han sido propuestas como una tecnica de verificacion del software desde hace mas de 
treinta afios. Las demostraciones formales de programas pueden ciertamente ser construidas 
para pequenos sistemas. Sin embargo, las dificultades practicas para probar que un sistema 
satisface sus especificaciones son tan grandes que pocas organizaciones consideran las prue- 
bas de correccion como uno de los costes. Sin embargo, para algunas aplicaciones criticas, 
puede ser rentable desarrollar pruebas de correccion para incrementar la confianza de que el 
sistema satisfaga sus requerimientos de seguridad o proteccion. En concreto, este es el caso 
cuando la funcionalidad de seguridad critica puede seraislada en subsistemas muy pequenos 
que pueden ser especificados formalmente. 

Aunque puede no ser rentable desarrollar demostraciones de correccion para la mayoriade 
los sistemas, a veces es posible desarrollar argumentos de seguridad simples que demuestran 
que el programa satisface sus obligaciones de seguridad. En un argumento de seguridad, no 
es necesario probar que la funcionalidad del programa es la que se especifico. Solo es nece- 
sario demostrar que la ejecucion del programa no conduce a un estado inseguro. 

La tecnica mas efectiva para demostrar la seguridad de un sistema es la demostracion por 
contradiccion. Se comienza suponiendo que se esta en un estado no seguro, el cual ha sido 
identificado por un analisis de contingencias del sistema, y que puede ser alcanzado ejecu- 
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- The msuUn dose to be delivered is a function of 

/ - Nood sugar level, the previous dose delivered and 

- the time of detivery of the previous dose 

currenfDose — compute! nsulin 0; 

// Safety check— adjust currenfDose if necessary 

//jf-statement 1 

if (previousDose — 0) 

if (currenfDose > 16) 

currenfDose -16 ; 

) 

dse 

if (currenfDose > (previousDose * 2)) 

currenfDose - previousDose * 2; 

// tf-statement 2 

if ( currenfDose < minimumDose) 

currenfDose - 0; 
eise if (currenfDose > maxDose) 

currenfDose - maxDose; 
administerlnsulin (currenfDose); 

tando el programa. Se describe un predicado que define este estado no seguro. A continua- 
cion, se analiza el codigo de forma sistematica y se muestra que, para todos los caminos del 
programa que conducen a ese estado, la condicion de terminacion de estos caminos contradi- 
ce el predicado no seguro. Si este es el caso, la suposicion inicial de un estado inseguro es in- 
correcta. Si se repite esto para todas las contingencias identificadas, entonces el software es 
seguro. 

Como ejemplo, consideremos el codigo de la Figura 24.6, que podria ser parte de la im- 
plementacion del sistema de suministro de insulina. Desarrollar un argumento de seguridad 
para este codigo implica demostrarque la dosis de insulina administrada nunca es mayor que 
algun nivel maximo establecido para cada individuo diabetico. Por lo tanto, no es necesario 
probar que el sistema suministra la dosis correcta, sino simplemente que nunca suministra una 
sobredosis al paciente. 

Para construir un argumento de seguridad, se identifica la precondicion para el estado in- 
seguro que, en este caso, es que currentDose > maxDose. Despues se demuestra que todos 
los caminos del programa conducen a una contradiccion de estaasercion no segura. Si este es 
el caso, la condicion no segura no puede sercierta. Por lo tanto, el sistema es seguro. Se pue- 
den estructurar y presentar los argumentos de seguridad de forma grafica tal y como se mues- 
tra en la Figura 24.7. 

Los argumentos de seguridad, segun se refleja en la citada figura, son mucho mas cortos 
que las verificaciones formales de sistemas. Primero se identifica todos los posibles caminos 
que conducen a! estado potencial mente inseguro. Se trabaja hacia atras a partir de este esta- 
do no seguro y se considera la ultima asignacion de todas las variables de estado en cada ca- 
mino que conduce a el. Pueden omitirse los calculos previos (como la sentencia if 1 en la Fi- 
gura 24.7) en el argumento de seguridad. En este ejemplo, todo lo que se necesita saber es el 
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Contradicci6n 



currentDose >= mitiimumDose and 
currentDose <= maxDose 
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no ejecutada 



Figura 24.7 
Argumento informal 
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de contradicciones. 
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conjunto de posibles valores de currentDose inmediatamente antes de que el metodo admi- 
nisterlnsulin sea ejecutado. 

En el argumento de seguridad mostrado en la Figura 24.7, existen tres posibles caminos en 
el programa que conducen a la llamada al metodo administerlnsulin. Queremos demostrar 
que la cantidad de insulina suministrada nunca excede del valor de maxDose. Se consideran 
todos los posibles caminos hastaadministerlnsulin: 
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24.2.2 G a rant fa del proceso 

En la introduccion de este capitulo ya se ha puesto de manifiesto la importancia de garantizar 
la calidad del proceso de desarrollo del sistema. Esto es importante para todos los sistemas 
criticos, pero es particularmente importante para los sistemas de seguridad criticos. Existen 
dos razones de esto: 

1. Los accidentes son eventos raros en los sistemas criticos y puede ser practicamente 
imposible simularlos durante las pruebas de un sistema. No pueden realizarse pruebas 
extensivas para replicar las condiciones que conducen a un accidente. 

2. Los requerimientos de seguridad, tal y como se ha visto en el Capitulo 9, son a me- 
nudo requerimientos «no deberia» que excluyen comportamientos del sistema no se- 
guros. Es imposible demostrar de forma concluyeme a traves de las pruebas y otras ac- 
tividades de validacion que estos requerimientos se han alcanzado. 

El modelo de ciclo de vidapara el desarrollo de sistemas de seguridad criticos (Capitulo 9, 
Figura 9.7) deja claro que deberia prestarse atencion a la seguridad durante todas las etapas 
del proceso del software. Esto significa que las actividades especificas de garantia de calidad 
deben incluirse en el proceso. Estas incluyen: 

1. Lacreacion de un sistema de monitorizacion y registro de contingencias que sigauna 
trazadesde el analisis preliminarde contingencias hastalas pruebas y la validacion del 
sistema. 

2. La designacion de los ingenieros de seguridad del proyecto que tienen responsabili- 
dad explicita en aspectos de seguridad del sistema. 

3. El uso frecuente de revisiones de seguridad durante todo el proceso de desarrollo. 

4. La creacion de un sistema de certificacion de seguridad en el que la seguridad de los 
componentes criticos es certificada formalmente. 

5. El uso de un sistema de gestion de configuraciones muy detallado (vease el Capitulo 
29), que seutilizaparahacerunseguimientode toda ladocumentacionrelacionada con 
la seguridad y tenerla a mano junto con la documentacion tecnica asociada. Es im- 
portante tener procesos de validacion rigurosos si un fallo en la gestion de configura- 
ciones implica que un sistema erroneo se entrega al cliente. 

Para ilustrar la garantia de seguridad, se utiliza el proceso de analisis de contingencias que 
es una parte esencial del desarrollo de sistemas de seguridad criticos. El analisis de contingen- 
cias esta relacionado con la identificacion de contingencias, su probabilidad, y la probabilidad 
dc que estas contingencias provoquen un accidente. Si cl proceso dc desarrollo incluye una Cla- 
ra trazabilidad desde la identificacion de contingencias hasta el sistema mismo, entonces se pue- 
de argumentar por que estas contingencias no provocan accidentes. Esto puede complementar- 
se con argumentos de seguridad, tal y como se explico en la Secci6n24.2. 1 . Cuando serequiera 
una certificacion externa antes de que el sistema sea utilizado (por ejemplo, en un avion), nor- 
malmente una condicion de certificacion es que la trazabilidad pueda ser demostrada. 

El documento central de seguridad es el registro de contingencias, en el que se documen- 
tan y se lleva un seguimiento de las contingencias identificadas durante el proceso de especi- 
ficacion. A continuacion, este registro de contingencias se utiliza en cada etapa del proceso 
de desarrollo del software para evaluar como esa etapa del desarrollo ha tenido en cuenta las 
contingencias. Un ejemplo simplificado de un registro de contingencias para el sistema de su- 
ministro de insulina se muestra en la Figura 24.8. Este formulario documenta el proceso de 
analisis de contingencias y muestra los requerimientos de diseno que han sido generados du- 
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Figura 24.8 Una 
pagina simplificada 
del registro 
de contingencias. 



t . El sistema debera induir software de autovertfkaddn que probara el sistema del sensor, el re- 
loj y el sistema de insulins suministrada. 

2. 0 software de autocomprobaddn debera ejecutarse una vez por minuto. 

3. En caso de que el software de autoverificadon descubra un defecto en cualquiera de los com- 
ponentes del sistema, se debera emitir una alarma sonora y ei despliegue de la bomba indi- 
cate el nombfe del componente donde el defecto se descubrio. El suministro de insulina se 
suspendera. 

4. Q sistema debera incorporar un sistema de animation que le permita al usuario del sistema 
modificar la dosis calculada de insulina que suministrara el sistema. 

5. La carttidad a modrficar no debe ser mas grande que un valor prestableddo seleccionado 
cuarxfo el sistema haya sido configurado por el personal medico. 



rante este proceso. Estos requerimientos de diseiio intentan asegurar que el sistema de con- 
trol nunca puede entregar una sobredosis de insulina a un usuario de la bomba de insulina. 

Tal y como se muestra en la Figura 24.8, los individuos que tengan las responsabilidades 
en la seguridad deberian ser identificados explicitamente. Losproyectos de desarrollo de sis- 
temas de seguridad criticos deberian tener siempre un ingeniero de seguridad del proyecto que 
no este implicado en el desarrollo del sistema. La responsabilidad del ingeniero es asegurar 
que se hagan y documenten las comprobaciones adecuadas de seguridad. El sistema puede 
tambien requerir un asesor de seguridad independiente proveniente de una organizacion ex- 
terna, que informe directamente al cliente sobre cuestiones de seguridad. 

En algunos dominios, los ingenieros del sistema que tienen responsabilidades de seguri- 
dad deben ser certificados. En el Reino Unido, esto significa que tienen que haber sido acep- 
tados como miembros de uno de los institutos de ingenieria (civil, electrico, mecanico, etc.) 
y tienen que ser ingenieros diplomados. Los ingenieros sin experiencia o poco cualificados 
no deben tener responsabilidades de seguridad. 

Esto no se aplica actualmente a los ingenieros del software, aunque ha habido un gran de- 
bate sobre la concesion de licencias a ingenieros del software en varios estados de los Esta- 
dos Unidos (Knight y Leveson, 2002; Bagert, 2002). Sin embargo, los futuros estandares de 
procesos para el desarrollo de software de seguridad critico puede requerir que los ingenieros 
de seguridad del proyecto sean ingenieros certificados formalmente con un nivel de entrena- 
miento minimo definido. 



24.2.3 Comprobaciones de seguridad en tlempo de ejecucion 



Se ha descrito la programacion defensiva en el Capitulo 20. en la cual se anaden sentencias 
redundantes a un programa para monitorizar su funcionamiento y comprobar posibles defec- 
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static void administertnsulin ( ) throws SafetyException { 

int maxlncrements - InsuKnPump.rnaxDose / 8 ; 
int increments — InsulmPump.airrerttDose / 6 ; 

// assert currentDose <> InsuSnPutnpjnaxDose 

if (tnsdinPmnp.curTefitDose > InsuSnPwnpjnaxDose) 
throw new SafetyException (Pump.doseHigh); 

else 

for 0«t i»l ; r<- increments; 
t 

generateSignal 0 ; 
if 0 > maxkiaerrients) 

throw new SafetyException {Pump.tncorrect1ncrernents); 
}//forloop 

} //admintsterlnsutin 

tos en el sistema. La misma tecnica puede utilizarse para monitorizar dinamicamente los sis- 
temas de seguridad criticos. Puede anadirse codigo de comprobacion del sistema que com- 
pruebe una restriccion de seguridad. Este lanza una excepcion si se viola dicha restriccion. Las 
restricciones de seguridad que deberian cumplirse siempre en puntos concretos de un pro- 
grama pueden expresarse como aserciones. Las aserciones son predicados que describen con- 
diciones que deberian cumplirse antes de que pueda ejecutarse la siguiente sentencia. En sis- 
temas de seguridad criticos, las aserciones deberian generarse a partirde la especificacion de 
seguridad. Las aserciones intentan asegurar el comportamiento seguro mas que un comporta- 
miento que este de acuerdo con su especificacion. 

Las aserciones pueden ser particularmente valiosas para garantizar la seguridad de las co- 
municaciones entre los componentes del sistema. Porejemplo, en el sistema de suministro de 
insulina, ladosis de insulina administradaimplicagenerar sefiales a labombade insulinapara 
suministrar un numero especifico de incrementos de insulina (Figura 24.9). El numero de in- 
crementos de insulina asociados con la dosis de insulina maxima permitida puede ser precal- 
culado e incluido como una asercion en el sistema. 

Si ha habido un error en el calculo de currentDose, que es la variable de estado que al- 
macena la cantidad de insulina a suministrar, o si este valor se ha danado de alguna manera, 
entonces se detectara en este momento. No se suministrara una dosis excesiva de insulina, ya 
que la comprobacion en el metodo asegura que la bomba no suministrara mas de maxDose. 

A partir de las aserciones de seguridad que estan incluidas como comentarios en el pro- 
grama, puede generarse codigo para comprobar estas aserciones. Puede verse esto en la Fi- 
gura 24.9, en donde la sentencia ifdespues del comentario de la asercion comprueba dicha 
asercion. Enprincipio, mucha de esta generacion de codigo puede ser automatizadautilizan- 
do un preprocesador de aserciones. Sin embargo, estas herramientas normalmente tienen que 
ser escritas de forma especial y el codigo de las aserciones se genera normalmente a mano. 

24.3 Valoracion de la proteccion 

La valoracion de la proteccion de un sistema esta adquiriendo una importancia creciente ya 
que cada vez mas sistemas criticos estan conectados a Internet y pueden ser accedidos por 
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cualquiera que tenga una conexion de red. Diariamente hay historias sobre ataques a sistemas 
basados en web, y los virus y los gusanos se distribuyen normalmente a traves de protocolos 
de Internet. Todo esto significaque los procesosdeverificaciony validacion para sistemas ba- 
sados en web deben centrarse en la evaluacion de la proteccion, en la que se prueba la habi- 
lidaddel sistemapararesistirdiferentes tipos de ataques; sin embargo, tal y como explica An- 
derson (Anderson, 2001), este tipo de evaluacion de la seguridad es muy dificil de llevar a 
cabo. Como consecuencia, los sistemas a menudo son desplegados con agujeros de seguridad 
que los intrusos utilizan para conseguir el acceso o para dafiar a estos sistemas. 

Fundamentalmente, la razon de por que la proteccion es tan dificil de evaluar, es que los 
requerimientos de proteccion, al igual que algunos requerimientos de seguridad, son requeri- 
mientos «no deberia». Es decir, especifican que es lo que no deberia ocurrir en lugar de la fun- 
cionalidad del sistema o del comportamiento requerido. Normalmente no es posible definir 
este comportamiento no deseado como simples restricciones que pueden ser comprobadas por 
el sistema. 

Si hay recursos disponibles, siempre puede demostrar que un sistema satisface sus reque- 
rimientos funcionales. Sin embargo, es imposible probarque un sistema no hace algo, por lo 
que, independientemente de la cantidad de pruebas, pueden quedar vulnerabilidades de pro- 
teccion en un sistema despues de que este haya sido desplegado. Incluso en los sistemas que 
han sido utilizados durante muchos anos, un intruso ingenioso puede descubriruna nueva for- 
ma de atacar e introducirse en lo que se pensaba que era un sistema protegido. Por ejemplo, 
el algoritmo RS A para encriptacion de datos que se penso durante muchos anos que era se- 
guro, fue violado en 1999. 

Existen cuatro aproximaciones complementarias para comprobar laproteccion: 

1. Validacion basada en la experiencia. En este caso, el sistema se analiza frente a ti- 
pos de ataques conocidos por el equipo de validacion. Este tipo de validacion se lle- 
va a cabo normalmente junto con la validacion basada en herramientas. Se pueden 
crear listas de comprobacion de problemas de proteccion conocidos (Figura 24. 10) 
paraayudaralproceso. Estaaproximacion puede utilizartoda la documentacion del 
sistema y podria ser parte de otras revisiones del sistema que comprueben errores u 
omisiones. 

2. Validacion basada en herramientas. En este caso, varias herramientas de proteccion, ta- 
les como comprobadores de contrasenas, se utilizan para analizar el sistema. Los com- 
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probadores de contrasenas detectan contraseiias inseguras tales como nombres comu- 
nes o cadenas de letras consecutivas. Esta es realmente una extension de la validacion 
basada en la experiencia, en donde la experiencia se incluye en la herramienta usada. 

3 . Equipos tigre. En este caso, se forma un equipo y se le da el objetivo de romper la pro- 
teccion del sistema. Estos simulan ataques al sistema y usan su ingenio para descubrir 
nuevas formas de comprometer la seguridad del sistema. Esta aproximacion puede ser 
muy efectiva, especialmente si los miembros del equipo tienen experiencia previa en 
introducirse en los sistemas. 

4. Verification formal. Un sistema puede ser verificado frente a una especificacion de 
proteccion formal. Sin embargo, al igual que en otras areas, la verificacion formal para 
la proteccion no se utiliza ampliamente. 

Es muy dificil para los usuarios finales de un sistema verificar su proteccion. Como con- 
secuencia, tal y como senalaGollmann (Gollmann, 1999), las organizacionesenNorteame- 
rica y en Europa han establecido conjuntos de criterios de evaluacion de proteccion que pue- 
den ser comprobados por evaluadores especializados. Los proveedores de productos software 
pueden someter sus productos para su evaluacion y certificacion frente a estos criterios. 

Por lo tanto, si se tiene un requerimiento para un nivel particular de proteccion, se puede 
elegirun producto que haya sido validado para ese nivel. Sin embargo, muchos productos no 
estan certificados en cuanto a la proteccion o su certificacion se aplica a productos indivi- 
duales. Cuando el sistema certificado se utiliza junto con otros sistemas no certificados, como 
un software desarrollado localmente, entonces el nivel de proteccion del sistema completo no 
se puede evaluar. 

24.4 Argumentos de contabilidad y de seguridad 

Los argumentos de seguridad y, mas genericamente, los argumentos de confiabilidad son do- 
cumentos estructurados que proporcionan argumentos detallados y evidencias de que un sis- 
tema es seguro o de que se ha alcanzado un nivel requerido de confiabilidad. Para muchos ti- 
pos de sistemas criticos, la produccion de un argumento de seguridad es un requerimiento 
legal, y el argumento debe satisfacer alguna certificacion antes de que el sistema pueda ser 
desplegado. 

Los reguladores son creados por los gobiernos para asegurarque las industrias privadas no 
se aprovechan de no seguirestandares nacionales para seguridad, proteccion, y asi sucesiva- 
mente. Existen reguladores en muchas industrias diferentes. Por ejemplo, las lineas aereas son 
reguladas por las autoridades de la aviacion nacional tales como la FA A (en Estados Unidos) 
y la C A A (en el Reino Unido). Los reguladores de las lineas ferroviarias existen para asegu- 
rar la seguridad de las vias de tren, y los reguladores nucleares deben certificar la seguridad 
de una planta nuclear antes de que sea puesta en marcha. En el sector bancario, los bancos na- 
cionales sirven como reguladores, estableciendo procedimientos y practicas para reducir la 
probabilidad de fraude y proteger a los clientes de los bancos de las practicas bancarias arries- 
gadas. A medida que los sistemas software son cada vez mas importantes en la infraestructu- 
ra critica de los paises, estos reguladores estan cada vez mas relacionados con los argumen- 
tos de seguridad y confiabilidad para sistemas software. 

La funcion de un regulador es comprobar que un sistema finalizado es tan seguro como 
practico,por loque lafiguradel regulador se ve implicadaprincipalmente cuando se hacom- 
pletado el desarrollo del proyecto. Sin embargo, los reguladores y los desarrolladores rara- 
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mente trabajan de forma aislada; se comunican con el equipo de desarrollo para establecer que 
tiene que incluirse en el argumento de seguridad. El regulador y los desarrolladores exami- 
nan conjuntamente los procesos y los procedimientos para asegurarse de que estos estan sien- 
do establecidos y documentados para satisfacer al regulador. 

Por supuesto, el software en si mismo no es peligroso. Solo cuando este esta embebido en 
un gran sistema socio-tecnico o basado en computadora, los fallos de ejecucion de dicho soft- 
ware pueden provocar fallos en otros equipos o procesos que a su vez pueden ocasionar le- 
siones o muertes. Por lo tanto, un argumento de seguridad del software siempre forma parte 
de un argumento de seguridad de un sistema mas amplio que demuestra la seguridad del sis- 
tema completo. Cuando se construye un argumento de seguridad del software, se tienen que 
relacionar los fallos de ejecucion del software con fallos del sistema mas amplios y demos- 
trar que estos fallos de ejecucion no ocurriran o que no se propagaran, de tal forma que pue- 
dan producirse fallos peligrosos del sistema. 

Un argumento de seguridad es un conjunto de documentos que incluye una descripcion del 





Description del sistema 


Una descripcion del sistema y de sus componentes cffticos. 


Requerimientos de seguridad 


Los requerimientos de seguridad abstrafdos de la espedfkadon de requerimientos del 
sistema. 


Analisis de riesgos y contingentias 


Documentos que describes las contingencies y riesgos que tienen que identrficarse y las 
medidas que hay que tomar para reducir el riesgo . 


Analisis del diseflo 


Conjunto de argumentos estructurados que justifican por que el diseflo es seguro. 


Verification y valid adbn 


Descripcion de los procedimientos de V & V utilizadosy, cuando sea adeaiado, los pla- 
nes de prueba del sistema. 


Informes de revision es 


Informes de todos las revistones de diseflo y seguridad 


Competencias del equipo 


Evidencia de la cornpetentia de todos los equipos hnpticados en el desarrollo y valida- 
tion de sistemas seguros. 


Procesos de garantfa de caHdad 


Irtformes de kx procesos de garantfa de calidad Hevados a cabo durante e) desarrollo del 
sistema. 


Procesos de gestion de camhios 


Informes de todos Jot cembios propuestos, acciooes tomadas y, cuando sea ap/opiado, 
justrrkacidn de la seguridad de estos cambios. 


Argumentos de seguridad asodados 


Referenda* a otros argumentos de seguridad que pueden inftuir en un argumento de se- 
guridad. 



Figura 24.11 Componentes de un argumento de seguridad del software. 
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Figura 24.12 
Estructura de un 
argumento. 




Un componente clave de un argumento de seguridad es un conjunto de argumentos 16- 
gicos para la seguridad del sistema. Estos pueden ser argumentos absolutos (el evento X 
ocurrirao no) o argumentos probabilisticos (laprobabilidaddel evento X es O. Y); al com- 
binarlos, estos deberian demostrar la seguridad. Tal y como se muestra en la Figura 24. 12, 
un argumento es una relacion entre lo que se piensa que debe ser un argumento (una exi- 
gencia) y un conjunto de evidencias que han sido observadas. El argumento esencialmente 
explica por que la exigencia (que generalmente es que algo es seguro) puede inferirse a par- 
tir de la evidencia disponible. Naturalmente, dada la naturaleza multinivel de los sistemas, 
las exigencias se organizan en unajerarquia. Para demostrar que una exigencia de alto ni- 
vel es valida, primero se tiene que trabajar a traves de los argumentos desde exigencias de 
niveles inferiores. La Figura 24.13 muestra una parte de estajerarquia de exigencias para 
labombade insulina. 

Como dispositivo medico, el sistema de bombade insulina tiene que ser certificado exter- 
namente. Por ejemplo, en el Reino Unido, la Direccion de Dispositivos Medicos tiene que 
emitirun certificado de seguridad para cualquier dispositivo medico que se venda en el Reino 



Figura 24.13 
Jerarquia 

de exigencias en el 
argumento de 
seguridad para la 
bomba de insulina. 




En un funcionamiento 

normal, la dosis 
maxima calculada no 
excedera de maxDose 



CAP ITU LO 24 • PuntosClave 



537 



Unido. Pueden tener que generarse distintos argumentos para demostrar la seguridad de este 
sistema. Porejemplo, el siguiente argumento podriaformar parte de un argumento de seguri- 
dad para la bomba de insulina. 

Exigencia: La dosis individual maxima de insulina calculada por la bomba no excede- 
ra de maxDose. 

Evidencia: Argumento de seguridad para la bomba de insulina (Figura 24.7). 
Evidencia: Conjuntos de datos de prueba para la bomba de insulina. 
Evidencia: Informe de analisis estatico para el software de la bomba de insulina. 
Argumento: El argumento de seguridad presentado muestra que la dosis maxima de in- 
sulina que puede ser calculada es igual a maxDose. 

En 400 pruebas, el valor de Dose fue calculado correctamente y nunca ex- 
cedio de maxDose. 

El analisis estatico del software de control no revelo anomalias. 
En definitiva, es razonable admitir que la exigencia esta justificada. 

Por supuesto, este es un argumento muy simplificado, y en un argumento de seguridad real 
deberian presentarse referencias detalladas de la evidencia. Debido a que requieren detalles, 
los argumentos de seguridad son, por lo tanto, documentos muy extensos y complejos. Estan 
disponibles distintas herramientas software para ayudar a su construccion, y se han incluido 
enlaces a estas herramientas en las paginas web del libro. 



PUNTOS CLAVE 

• Las pruebas estadisticas se utilizan para estimar la fia bjljdad del software. Se encargan de probar el sistema 
con datos de prueba que reflejen el perfil operacional del software. Los datos de prueba pueden generarse 
automatlcamente. 

• Los modelos de crecimiento de Habilidad muestran el cambio en la Habilidad a medida que los defectos son 
eliminados del software durante el proceso de pruebas. Los modelos de fiabilidad pueden utilizarse para pre- 
decir cuando se alcanzaran los requerimientos de fiabilidad. 

• Las demostraciones de seguridad son una tecnica efectiva de garantia de seguridad de los productos. Mues- 
tran que una condicion identificada como peligrosa nunca puede ocurrir. Normalmente son mas faciles que 
probar que un programa satisface sus especificaciones. 

• Es importante tener un proceso certificado bien definido para el desarrollo de sistemas de seguridad cnticos. 
El proceso debe incluir la identificacionymonitorizacionde contingencias potenciales. 

La valid aci on de la seguridad puede realizarse utilizando analisis basado en (a experiencia, analisis basado 
en herramientas, o«equipostigre»quesimulan ataques a I sistema. 

• Los argumentos de seguridad recogen toda la evidencia que demuestra que un sistema es seguro. Estos ar- 
gumentos de seguridad se requieren cuando un reguladorexterno debe certificar el sistema antes de que este 
sea utilizado. 
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LECTURAS ADICION ALES 



«Best practices in code inspection for safety-critical software". Este trabajo practico presenta una lista de reco- 
mendaciones para inspeccionar y revisar software de seguridad critlco. [J. R. de Almeida et ai, IEEE Software, 20(3), 
mayo-junio de 2003.] 

«Statically scanning Java code: Finding security vulnerabilities*). Este es un buen trabajo sobre como evitarvulne- 
rabilidades de seguridad en general. Muestra como ocurren estas vulnerabilidades y como pueden ser detectadas 
utilizando un analizador estatico. [J. Viega et ai, IEEE Software, 17(5), septiembre-octubre de 2000,] 

Software Reliability Engineering: More Reliable Software, Faster Development and Testing. Este es probablemente 
el libro definitivo sobre el uso de perfiles operactonales y modelos de Habilidad para la evaluacion de la Habilidad. 
Incluye detalles de experiencias con pruebas estadisticas [J. D. Musa, 1998, McGraw-Hill.] 

Safety-critical Computer Systems. Este excelente libro de texto incluye un capitulo particularmente bueno sobre el pa- 
pel de los metodos formales en el desarrollo de sistemas de seguridad criticos. (N. Storey, 1996, Addison-Wesley.) 

Safeware: System Safety and Computers. Este trabajo incluye un buen capitulo sobre validacion de sistemas de se- 
guridad criticos con mas detalle del que se proporciona aqui sobre el uso de argumentos de seguridad basados en 
arboles de defectos. (N. Leveson, 1995, Addison-Wesley.) 



EJERCICIOS m 

241 Describa comoprocederia para validar la especif icacion de fiabilidad para un sistema de supermercados 
que usted especifico en el Ejercicio 9.9. Su respuesta debe incluir una description de cualquier herra- 
mienta de validacion que pudiera utilizarse. 

242 Explique por que espracticamenteimposible validar las especif icacionesde fiabilidad cuando estas seex- 
presan enterminosde un numero muypequehodefallossobreeltiempodevida total de un sistema. 

243 Utilizando la literatura como informacion de referenda, escriba un informe para la gestion (para quien no 
tenga experiencia en esta area) sobre el uso de los modelos de crecimiento de fiabilidad. 

244 iEs etico para un ingeniero el aceptar que se entregue a un cliente un sistema software con defectos co- 
nocidos? ^Existe alguna diferencia si al cliente se le informa de la existencia de estos defectos con ante- 
lacion? ^Podria ser razonable imponer exigencias sobre la fiabilidad del software en tales circunstancias? 

245 Explique por que el asegurar la fiabilidad del sistema no es una garantia de un sistema seguro. 

246 El mecanismo de control de bloqueo de puertas en una utilidad para un almacen de desperdicios nuclea- 
res se diseha para ser una funcionalidad segura. Dicho mecanismo asegura que la entrada al almacen solo 
se permite cuando los escudos de radiacion estan activados o cuando el nivel de radiacion en una habita- 
cion caiga por debajo de algun valor determinado (dangerLevel). Es decir: 

(i) Si los escudos de radiacion remotamente controlados estan activados dentro de la habitacion, la 

puerta puede ser abierta por un operador autorizado, 
(ij) Si el nivel de radiacion esta por debajo de un valor determinado, la puerta puede ser abierta por 
un operador autorizado. 

(ui) Un operador autorizado es identificado por la introduccion de un codigo autorizado de entrada de 
puertas. 
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1 entryCode - loek-getErrtryCode 0 ; 

2 if (entiyCode =™ lock-authorisedCode) 

3 { 

4 shieWStatus = Shield.gctStatus 0; 

5 radiation Level = RadSertsof.get Q; 

6 if (radiationLevel < dangerLevel) 

7 state = safe; 

8 else 

9 state = unsafe; 

1 0 if {shieWStatus = Shield.inPlaceO ) 

1 1 state - safe; 

12 if (state = safe) 

13 { 

1 4 Door.locked « false ; 

15 Door.unlock 0; 

16 } 

17 else 

18 { 

Id DoorJock ( ); 

20 Door.locfced ?= mte ; 
23 J 

21 ) 
4 

5 



El codigo Jav^ mostrado en la Figura 24.14 controla e( mecanismo de bloqueo de puertas. Note que el 

estado seguro esgque la entrada no deberia permitirse. Desarrolle un argumento de seguridad que mues- 

tre que este codi&o es potencialmente no seguro. Modifique el codigo para hacerlo seguro. 
10 

24.7 Usando la espeqjficacion para el calculo de la dosis suministrada dado en el Capitulo 10 (Figura 10. 11), es- 

criba un metod4ZJava computelnsulin como el usado en la Figura 24.6. Construya un argumento informal 

de seguridad de^ue este codigo es seguro. 
14 

24.8 Sugiera como rJSdria validar un sistema de proteccion de contrasefias para una aplicacion que usted ha 

desarrollado. E^lique la funcion de cualquier herramienta que piense que pueda ser util. 
17 

2A9 (,P° r qus es neci&ario incluir detalles de los cambios del sistema en un argumento de seguridad del soft- 
ware? 19 
Figura 24.14 

CofrrWftdor p ; a¥a m flF e cuatro^tipos de sistemas que podrian requerir argumentos de segundad del software del sistema. 

que usted formo parte de un equipo que desarrollo software para una planta quimica, que fallo 
de alguna manera, provocando un serio incidente de contaminacion. Su jefe es entrevistado en la televi- 
sion y afirma que el proceso de validacion ha sido completo y que no existen defectos en el software. De- 
clare que los problemas deben ser debidos a procedimientos de uso no adecuados. Un periodista se acer- 
ca a usted para preguntarle su opinion. Comente como podria manejar tal entrevista. 



DE PERSONAL 



Capftulo 25 Gestion de personal 

Capftulo 26 Estimacion de costes del software 

Capftulo 27 Gestion de calidad 

Capftulo 28 Mejora de procesos 

Capftulo 29 Gestion de configuraciones 



A veces se sugiere que la diferencia clave entre los ingenieros de software y otros pro- 
gramadores es un proceso gestionado. Esto significa que el desarrollo de software se Ne- 
va a cabo dentro de una organizacion y esta sujeta a calendario, presupuesto y restric- 
ciones organizacionales. Listed lo puede contrastar con un desarrollo open-source, el 
cual es una actividad larga y voluntaria. Los desabolladores de open-source toman sus 
propias decisiones acerca de cuando y como trabajaran en el desarrollo de este softwa- 
re, y la calidad de su trabajo muestra que software de calidad no tiene que ser estricta- 
mente gestionado. 

Sin embargo, la mayoria de los proyectos no pueden desarrollarse utilizando una 
aproximacion open-source —este modelo de desarrollo solo es adecuado para sistemas 
de infraestructuras como sistemas operativos, seridores web, compiladores, etc—. El des- 
arrollo de aplicaciones mas especializado es siempre un proceso gestionado. Los capi- 
tulos de esta parte del libro amplian la introduccion a la gestion del Capitulo 5 yexpon- 
dran los siguientes temas: 

1. El Capitulo 25 trata acerca de la gestion de personal. No es un tema tecnico y por 
el lo no suele aparecer en los libros de ingenieria del software. Sin embargo, bajo 
mi experiencia, gestionar personal es una actividad critica en la gestion de pro- 
yectos software. Mi objetivo aqui es introducirle en las cuestiones y problemas de 
la gestion de personal; hablando acerca de la seleccidn y motivacion del perso- 
nal, la gestion de grupos en proyectos y finalmente acerca del modelo SEI de la 
Madurez de la Capacidad del Personal. 

2. En el Capitulo 26 me centrare en la estimacion de costes software. Hablare acer- 
ca de la productividad software y de una variedad de tecnicas de estimacion de 
costes. Existe mucha incertidumbre en esta area y muchas personas creen que la 
mejorforma de resolver esta cuestion es con el modelado algoritmico de costes. 
Yo expondre aqui el modelo COCOMO II, pero como un modelo global, hacien- 
do una breve introduccion de sus caracteristicas. 

3. Los Capitulos 27 y 28 tratan de la gestion de la calidad. El Capitulo 27 nos intro- 
ducira en las tecnicas para garantizary mejorar la calidad del software. En el Ca- 
pitulo 28 se vuelve a discutir sobre la mejora de procesos software —como se 
pueden cambiar lo procesos software para mejorar los atributos de producto y de 
proceso. 

4. Finalmente, el Capitulo 29 habla sobre la gestion de configuraciones. Este tema 
es importante en sistemas grandes que son desarrollados por equipos. Sin em- 
bargo, la necesidad de la gestion de configuraciones no siempre es obvia para los 
estudiantes que solo ban actuado como personal de desarrollo de software. Yo 
introducirevariosaspectosen este tema como la planificaciondelaconfiguracion, 
gestion de versiones, construccion del sistema y gestion de cambios. 



25 

Gestion 
de personal 



Objetivos 

El objetivo de este capitulo es mostrar la importancia de las 
personas en et proceso de ingenieria del software. Cuando termine 
de leer este capitulo: 

• comprendera algunos de los puntos involucrados en la 
seleccion y retencion de personal en una organizacion de 
desarrollo de software; 

• comprendera los factores que influyen en la motivacion 
individual y sus implicaciones para los gestores de proyectos 
software; 

• comprendera los elementos clave del trabajo en equipo, 
principalmente la composicion, la cohesion, la comunicacion y 
ta organizacion; 

• habra sido introducido en el Modelo de Madurez de la 
Capacidad del Personal — un modelo que es un marco de 
trabajo para resaltar las capacidades de los ingenieros del 
software en una organizacion. 

Contenidos 

25.1 Seleccion de personal 

25.2 Motivacion 

25.3 Gestionando grupos 

25.4 El Modelo de Madurez de la Capacidad del Personal 
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El personal que trabaja en una organizacion software es su principal activo. Representa el capi- 
tal intelectual, y es mision de los gestores asegurar que la organizacion obtenga los mejores be- 
neficios posibles al invertir en las personas. En las companias y economias con exito, esto se 
cumple cuando las personas son respetadas por la organizacion. Dichas personas deberan tener 
un nivel de responsabilidad y se les deberan asignar premios de acuerdo con sus capacidades. 

Por lo tanto, la gestion efectiva se refiere a la gestion del personal en una organizacion. Los 
gestores de proyectos tienen que resolver problemas tecnicos y no tecnicos, utilizando a las 
personas de su equipo de la forma mas efectiva posible. Tienen que motivar a la gente, plani- 
ficar y organizar su trabajo y asegurar que este se realice de manera adecuada. La mala ges- 
tion del personal es uno de los factores mas importantes en el fracaso de los proyectos. 

Desgraciadamente, esta mala gestion es demasiado comun en laindustriadel software. Los 
gestores fallan al tomar nota de las limitaciones individuales e imponer metas inalcanzables 
a los equipos del proyecto. Equiparan la gestion con reuniones, donde la gente colabora en el 
proyecto. Pueden aceptar nuevos requerimientos sin el analisis adecuado de lo que esto sig- 
nifica para el equipo del proyecto. A veces, ven su papel como una explotacion de su perso- 
nal, en lugar de trabajar con ellos para que su trabajo pueda contribuir a metas tanto organi- 
zacionales como personales. 

Desde nuestro punto de vista, hay cuatro factores criticos en la gestion de personal: 

1 . Objetividad. El personal del proyecto debe ser valorado de forma equitativa. Mientras 
que alguien no espere, que todas las recompensas sean identicas, la gente sentira que 
su contribucion en la organizacion es infravalorada. 

2. Respeto. Las personas tienen diferentes habilidades y los gestores deben respetar es- 
tas diferencias. Todos los miembros del equipo deben dar una oportunidad para hacer 
una contribucion. En algunos casos, por supuesto, usted se encontrara con gente que 
simplemente no se ajusta a un equipo, y no puede continuar, pero es importante no sa- 
car conclusiones acerca de esto. 

3. Incorporation. La gente contribuye efectivamente cuando siente que se la escucha y se 
toma nota de sus propuestas. Es importante desarrollar un entorno de trabajo donde to- 
dos los puntos de vista, hasta el de la persona mas novata, se tomen en consideracion. 

4. Honestidad. El gestor de proyectos siempre debe de ser honesto con lo que esta yen- 
do bien y con lo que esta yendo mal en el equipo. Debe ser honesto en lo que se re- 
fiere a su nivel de conocimientos tecnicos y debe dar la razon al personal con masco- 
nocimientos cuando sea necesario. Si no es honesto, se encontrara fuera de lugar en 
algunas ocasiones, y perdera el respeto del grupo. 

El objetivo en este capitulo es introducir al lector en algunos elementos que los gestores 
de proyectos software pueden encontrar, y proveerle de informacion que le ayude a entender 
estos elementos. La gestion, desde mi punto de vista, solo puede ser aprendida con la expe- 
riencia; por lo tanto, el papel del libro es ayudarle a aprender de experiencias previas. Para 
llegar a ser un buen gestor de personal no sera suficiente con la simple lectura de este capitu- 
lo. Sin embargo, es de esperar que este material ayude a entender los problemas que los ges- 
tores encuentran cuando dirigen equipos de individuos con talento tecnico. 

25.1 Seleccion de personal 

Una de las tareas mas importantes de un gestor de proyectos es seleccionar al personal que 
trabajara en el proyecto. En casos excepcionales, los administradores de proyectos pueden de- 
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signar a las personas que mejor se adecuan a un trabajo, independientemente de sus otras res- 
ponsabilidades o de las consideraciones de presupuesto. Sin embargo, por lo general, los ad- 
ministradores de proyectos no tienen una libre eleccion de personal. Tienen que utilizar a 
quien este disponible en una organizacion, tienen que encontrar a las personas muy rapida- 
mente y cuentan conun presupuesto limitado. Esta limitacion de presupuesto restringe el nu- 
mero de costosos ingenieros con experiencia que pueden trabajar en el proyecto. 

La decision de quien sera designado para un proyecto, por lo general, se lleva a cabo uti- 
lizando tres tipos de informacion. 

1 . La informacion suministrada por los candidates acerca de sus conocimientos y expe- 
riencia (su CV). Esta suele ser la informacion mas fiable de la que se dispone parajuz- 
gar que candidatos son adecuados. 

2. Informacion obtenida al entrevistar a los candidatos. Las entrevistas pueden damos 
una buena vision de que candidatos son buenos comunicadores y cuando estos tienen 
buenas habilidades sociales. Sin embargo, las pruebas han mostrado que los entrevis- 
tadores son obligados a aceptar o rechazar candidatos haciendo rapidos juicios subje- 
tivos. Por lo tanto, las entrevistas no son metodos fiables parajuzgar las capacidades 
tecnicas. 

3. Recomendaciones de otras personas que han trabajado con los candidatos. Esto pue- 
de ser objetivo cuando se conoce a la persona que hace la recomendacion. De otro 
modo, las recomendaciones pueden no ser ciertas, por lo que deben tener poco peso 
en la decision a la hora de formar el equipo. 

La Figura 25.1 muestra un pequeno caso de estudio de los elementos que podemos en- 
contrar cuando evaluamos personal. Algunas lecciones tipicas que muestra el caso de uso son: 

1. Si usted estabuscando personas con determinadas habilidades dentro de lacompania, 
el gestor del proyecto en los cuales trabajan estas personas, puede no querer perder- 
los. A veces, tendremos que aceptar que personas trabajen a tiempo parcial en nues- 
tro proyecto. 

2. Pocos candidatos con determinadas habilidades, como diseno de interfaz de usuario e 
interfaz hardware. Usted puede no tener un amplio abanico de candidatos para estas 
tareas, especialmente si la compania no esta cerca de otras industrias software. 

3. Los recien titulados pueden no tener las habilidades que usted necesita, pero son nor- 
malmente entusiastas y pueden haber tenido contacto con la tecnologia mas actual. 

4. No intente siempre contratar a la persona con mas conocimientos tecnicos para un tra- 
bajo de desarrollo tecnico. En el caso de estudio, pudo ser necesaria la interaccion con 
los usuarios ancianos y Alice decidio que Carol seria mas comprensiva con sus pro- 
blemas. 

En la Figura 25.2 se muestra una tabla de los factores que pueden influir en su decision 
cuando este seleccionando personal. Los factores mas importantes varian dependiendo del do- 
minio de la aplicacion, del tipo de proyecto y de las habilidades de los otros miembros del 
equipo del proyecto. 

El gestor de proyectos puede encontrar problemas para descubrir gente con habilidades y 
experiencia apropiadas. Puede tener que formar un equipo utilizando ingenieros inexperi- 
mentados. Esto puede acarrear problemas porque los miembros del equipo no comprenden 
el dominio de la aplicacion o la tecnologia. Sin embargo, en proyectos de larga duracion, en- 
tender los conceptos y el dominio de la aplicacion es mas importante que los conocimientos 
especificos, en particular los lenguajes y metodos de programacion. Por lo tanto, a menos que 
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mhar en prosjamedon y en un entusiasta de la pragrainadon. Gastaba mucho de su tiempo 
trabajando en proyeetos open source y tenia unconodimentoteoricodeCyC-H-. 

Despues de errtrevtstar a ambos, Alka deddlo ofrecer d trabajo a Carol a pesar de que Daw* 
tenia profundos conedmlento* de programacidri. 



se necesiten conocimientos especificos en un lenguaje de programacion para un proyecto de 
corta duracion, es mejor elegir a personal con capacidad para resolver problemas o con do- 
minio de la aplicacion. Es relativamente sencillo aprender un nuevo lenguaje, pero mucho 
mas dificil desarrollar el conocimiento conceptual necesario para resolver problemas com- 
plejos. 

Algunas companias prueban a los candidatos. Incluyen pruebas de aptitud a la programa- 
cion y pruebas psicotecnicas donde los candidatos completan una serie de ejercicios en un pe- 
riodo de tiempo relativamente breve. Las pruebas psicotecnicas estan dirigidas a conseguir el 
perfil psicologico del candidate, indicando sus capacidades y habilidades para ciertos tipos de 
tareas. Algunos gestores consideran que estas pruebas son inutiles; otros piensan que prove- 
en informacion que ayuda a la seleccion del personal. Se duda si las pruebas de aptitud pro- 
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Experiencia en el dominio 
de la aplicaci6n 


Para desarrollar bien un sistema, los desarrolladores deben entender el dominio de la apti- 
carion. Es esencial que algunos miembros del equipo de desarroilo tengan alguna experiencia 
en el dominio de la aplicacidn. 


Experiencia en la plataforma 


Este factor es significante si la programaci6n a bajo nivel es necesaria. En otro caso, no es un 
atributo crftico. 


Experiencia en el lenguaje 
de programacion 


Normalmente esto solo es importante para proyectos de corta duracion donde no existe tiem- 
po suficiertte para aprender un nuevo lenguaje. Mientras que aprender el lenguaje propiamente 
dicho no es diffcil, empezar a utilizar las librerlas y componentes de forma competente puede 
llevar varios meses. 


Habilidad para resolver 
problemas 


Esto es muy importante para ingenieros de software, los cuales tienen que resolver constante- 
mente problemas tecnicos. Sin embargo, es casi imposible de juzgar sin conocer el trabajo del 
candidate. 


Soporte educativo 


Esto provee un indicador de los fundamentos basicos que el candidate debe conocer y de la 
habilidad para aprender. Este factor cada vez es mas trrelevante, puesto que los ingenieros ob- 
tienen experiencia a traves de los proyectos. 


Habilidad de comunicacion 


Esto es importante debido a que el personal del proyecto necesita comunicarse oratmente y 
por escrito con los otros ingenieros, administradores y dientes. 


Adaptabilidad 


La adaptabilidad se vaktra observando las diversas experiencias obtenidas por los candidates. 
Este es un atributo importante puesto que indica una habilidad para aprender. 


Actitud 


El personal del proyecto debe tener una actitud posrtiva con respecto a su trabajo y debe estar 
deseoso de aprender nuevas habilidades. Este es un atributo importante, pero a menudo muy 
diffcil de valorar. 


Personalidad 


Este es un atributo importante pero diffcil de valorar. Los candidates deben ser razonablemente 
compatibles con los otros miembros del equipo. Ningun ttpo de personalidad es mas o menos 
adecuada para la ingenierfa de software. 



Figura 25.2 Factores que determinan la seleccion de personal. 



veen informacion util acerca de la capacidad para resolver problemas. La resolucion softwa- 
re de problemas complejos es un proceso iterativo de la larga duracion. No parece que las ha- 
bilidades necesarias para la resolucion de problemas complejos sean comparables a las habi- 
lidades necesarias para completar pruebas de aptitud simples. 

La falta de personal tecnico con experiencia puede ser resultado de que, en algunas organi- 
zaciones, las personas con habilidades tecnicas rapidamente alcanzan una meta en sus carre- 
ras. Para progresar, deben tomar responsabilidades administrativas. La promocion de estas per- 
sonas aun status administrativo significa perder el ejercicio de sus habilidades tecnicas. Para 
evitar esta perdida, algunas companias desarrollaron estructuras paralelas de carreras tecnicas 
y administrativas de igual valor. Las personas con experiencia tecnica se consideran al mismo 
nivel que los administradores. Si un ingeniero desarrolla su carrera, se puede especializar en 
actividades tecnicas o de gestion y moverse entre ambas sin la perdida de su status o salario. 



25.2 Motivacion 



Uno de los papeles de los gestores de proyectos es motivar a las personas que trabajan con 
ellos. Motivacion significa organizar el trabajo y su entorno para estimular a las personas a 
trabajar de la forma mas efectiva posible. Si las personas no son motivadas, no se interesaran 
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en el trabajo que hacen. Estas trabajaran lentamente, cometeran mas errores y no contribui- 
ran a las metas del equipo ni de la organizacion. 

Maslow (Maslow, 1954) sugiere que la gente sea motivada satisfaciendo sus necesidades 
y que estas necesidades estan organizadas en una serie de niveles, que se muestran en la Fi- 
gura 25.3. El nivel mas bajo de esta j erarquia representa las necesidades fundamentales como 
comer, dormir, etc., y a continuacion, en el siguiente nivel, la necesidad de sentimos seguros 
en un entorno. Las necesidades sociales se refieren a la necesidad de sentirse parte de un gru- 
po social. Las necesidades de autoestima se refieren a sentirse respetados por los otros, y las 
necesidades de autorrealizacion se refieren a desarrollo personal. Las prioridades humanas son 
satisfacer las necesidades de los niveles inferiores, como estar hambriento, antes de satisfa- 
cer las necesidades, mas abstractas, de niveles superiores. 

Las personas que trabajan en organizaciones de desarrollo de software no estan general- 
mente hambrientas ni sedientas y por lo general no se sienten fisicamente amenazadas por su 
entorno. Por lo tanto, asegurar la satisfaccion de las necesidades sociales, de estima y de au- 
torrealizacion es mas importante desde un punto de vista administrativo: 

1. Satisfacer las necesidades sociales significa permitir que la gente tenga tiempo para 
conocer a sus companeros de trabajo y proveer lugares para que se conozcan. Esto es 
relativamente facil cuando todos los miembros del grupo de desarrollo trabajan en el 
mismo lugar, pero cada vez es mas habitual que los miembros del equipo no esten lo- 
calizados en el mismo edificio o incluso en la misma ciudad o estado. Pueden traba- 
jar en diferentes organizaciones o desde casa la mayor parte del tiempo. Las comuni- 
caciones electronicas, como el e-mail y la videoconferencia, pueden serusadas como 
ayuda al teletrabajo. Sin embargo, la experiencia con comunicaciones electronicas 
demuestra que estas no satisfacen realmente las necesidades sociales. Si el equipo de 
trabajo esta distribuido, deberian organizarse encuentros periodicos cara a cara, para 
que la gente haga un intercambio de experiencias directamente con los otros miembros 
del equipo. A traves de esta interaccion, la gente llega a formar parte de un grupo so- 
cial y puede ser motivada por las metas y prioridades del grupo. 

2. Para satisfacer las necesidades de estima, se necesita mostrar a la gente que es de gran 
valor para la organizacion. El reconocimiento publico de los logros es una forma sen- 
cilla pero efectiva de hacer esto. Obviamente, las personas tambien deben sentir que 
se les paga de acuerdo con el nivel que reflejan sus habilidades y experiencia. 

3. Finalmente, para satisfacer las necesidades de autorrealizacion se necesita dar a las 
personas responsabilidad de su propio trabajo, asignarles tareas cada vez mas exigen- 
tes (pero no imposibles) y proveerles un programa de capacitacion donde puedan 
desarrollar sus habilidades. 
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En la Figura 25.4 se ilustra un problema de motivacion con el que se encuentran los ges- 
tores frecuentemente. En este ejemplo, un miembro competente del grupo pierde interes en el 
trabajo y en el grupo. La calidad de su trabajo decae y empieza a ser inaceptable. Esta situa- 
cion tiene que ser resuelta con rapidez. Si no se zanja el problema, los otros miembros del gru- 
po llegaran a estar descontentos y a sentir que el reparto del trabajo es injusto. 

En este ejemplo, Alice trata de descubrir si las circunstancias personales de Dorothy po- 
drian ser el problema. Los problemas personales normalmente afectan a la motivacion, ya que 
la gente no puede concentrarse en su trabajo. Se debe dar tiempo y ayudar a la gente a resol- 
ver estas situaciones, aunque tambien debe dejarse claro que los empleados tienen unas res- 
ponsabilidades que cumplir. 

De hecho, el problema de motivacion de Dorothy es uno de los que surgen frecuente- 
mente cuando el proyecto se desarrolla en una direccion imprevista. La gente que espera 
hacerun tipo de trabajo puede hacer algo totalmente diferente. Esto comienza a serun pro- 
blema cuando las personas quieren desarrollar unas habilidades en alguna direccion que 
es diferente a la que toma el proyecto. En esas circunstancias, se puede decidir que miem- 
bros deberian dejar el equipo y encontrar oportunidades en otro lugar. En esta situacion, 
Alice decide convencer a Dorothy diciendole que ampliar su experiencia es un paso posi- 
tivo en su carrera. Ella da a Dorothy mas autonomia de diseno y organiza cursos de inge- 
nieria de software que le proporcionen mas oportunidades cuando el proyecto haya finali- 
zado. 

El principal problema que presenta el modelo de Maslow con la motivacion es que toma 
exclusivamente el punto de vista del individuo. No tiene en cuenta que de hecho la gente se 
siente parte de una organizacion, un grupo profesional, y por lo general de una cultura. No se 
trata simplemente de satisfacer las necesidades sociales; las personas pueden ser motivadas a 
traves de ayudar al grupo a conseguir las metas comunes. 

Ser miembro de un grupo cohesivo es altamente motivador para la mayoria de la gente. A 
las personas con trabajos que no les hacen sentirse realizadas, frecuentemente les gusta ir al 
trabajo porque estan motivadas por personas que trabajan con ellas y por el trabajo que esas 
personas hacen. Por lo tanto, es tan bueno pensar sobre la motivacion individual, como pen- 



Caso de estudio 2: Moavadon 

B proyecto de tecnologia de aslstencla de Alice empieza Men. ExJsten buenas relaclones errtre los 
miembros del equipo, y se desarrollan Ideas nuevas y creattvas. La compama decide desarrollar 
un slstema de mensajes pee r-to-peer usando televlslones dlgttales enlazadas a la red de alarmas. 
Sin embargo, unos meses mas tarde, Alice nota que Dorothy, la experts en diseno hardware, em- 
pieza a llegar al trabajo tarde, la calidad de su trabajo se deterlora, y cada vez mas parece que no 
se esta comunlcando con los otros miembros del equipo. 

Alice habla acerca del problema Informalmente con otros miembros del equipo para tratar de 
descubrir si las circunstancias personales de Dorothy nan camMado y si es poslble que esto la este 
afectando en el trabajo. Bios no saben nada, y Alice decide hablar con Dorothy para tratar de com- 
p render su problema. 

Despues de negar Inlclalmente que hay un problema, Dorothy admlte que ha perdldo Interes 
en su trabajo. Ella espera ba poder uHlbary desarrollar sus habilidades en Interlaces hardware. Sin 
embargo, la direccion que habla tornado el products le dejaba pocas oportunidades para esto. Ba- 
sl came rite, ella trabajaba como programador en C con otros miembros del equipo. Mlentras ad- 
mrte que el trabajo esta camMando, la preocupa que no esta desarrollando sus habilidades en In- 
terfaces hardware. Esta preocupada, porque encontrar un trabajo donde se trabaje con Interfaces 
Fleura 25 4 hardware sera dlf fell despues de este proyecto. Como no qulere dtsgustarse con el equipo reve- 

la lando que esta pensando en el slgulente proyecto, ha decldldo que lo mejores reduclral minlmo 
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sar en como el grupo puede ser motivado para alcanzar las metas de la organizacion. En la sec- 
cion siguiente se expondra la gestion de grupos. 

Enun estudio psicologico de motivacion, Bass y Dunteman (Bass y Dunteman, 1963) cla- 
sificaron a los profesionales en tres tipos: 

1. Los orientados a tareas, quienes estan motivados por el trabajo que hacen. En la in- 
genierladel software, son tecnicos que estan motivados por el reto intelectual de desa- 
rrollo software. 

2. Los orientados a simismos, quienes estan principalmente motivados por los exitos y 
el reconocimiento personal. Estan interesados en el desarrollo de software como me- 
dio para hacer cumplir sus propios propositos. 

3 . Los orientados a ;a interaction, quienes estan motivados por la presencia y acciones 
de sus compafteros de trabajo. Puesto que el desarrollo de software esta cada vez mas 
centrado en el usuario, los individuos orientados a la interaccion estan cada vez mas 
involucrados en ingenieria de software. 

Las personalidades orientadas a la interaccion por lo general gustan de trabajarcomo par- 
te de un grupo, mientras que las orientadas a las tareas y las orientadas a si mismas a menu- 
do prefieren trabajar solas. Es mas probable que las mujeres esten mas orientadas a la inter- 
accion que los hombres. A menudo, ellas son comunicadoras mas efectivas. Se hablara de la 
mezcla de estas personalidades dentro de grupos en la Seccion 25.3.2. 

Cada motivacion individual esta compuesta de elementos de cada clase, pero un tipo de 
motivacion es por lo general dominante en un momento dado. Sin embargo, las personalida- 
des no son estaticas y los individuos pueden cambiar. Por ejemplo, el personal tecnico que 
siente que no se le esta remunerando debidamente se puede convertir en orientado a si mis- 
mo y anteponer los intereses personales a las cuestiones tecnicas. 

25.3 Gestionando grupos 

Mucho del software profesional es desarrollado por equipos de proyectos que varian en ta- 
mano desde dos hasta varios cientos de personas. Sin embargo, puesto que es claramente im- 
posible que cada persona en un equipo grande trabaje con todos al mismo tiempo y de forma 
eficaz en un solo problema, estos grandes equipos por lo general se dividen en varios grupos. 
Cada grupo es responsable de un subproyecto que desarrolla algun subsistema. Como regla 
general, los grupos de proyectos de ingenieria de software normalmente no tienen mas de 
ocho o diez miembros. Cuando se utilizan grupos pequefios, los problemas de comunicacion 
se reducen. El grupo completo puede reunirse alrededor de una mesa y llevar a cabo reunio- 
nes en una oficina. 

Por lo tanto, hacer que un grupo trabaje eficazmente es una tarea critica de gestion. Ob- 
viamente, es importante que el grupo tenga el equilibrio correcto de habilidad y experiencia 
tecnicas y de personalidades. Sin embargo, los grupos exitosos son mas que una simple co- 
leccion de individuos con el equilibrio correcto de habilidades. Un buen grupo tiene un espi- 
ritu de equipo de tal forma que las personas involucradas se motivan por el exito del grupo, 
asi como por sus propias metas personales. 

Existen varios factores que influyen en el trabajo en grupo: 

1. La composition del grupo. ^Existe el equilibrio correcto de habilidades, experiencia 
y personalidades en el equipo? 
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2. La cohesion del grupo. ^Piensa el grupo en si mismo como un equipo mas que como 
una coleccion de individuos que trabajan juntos? 

3. La comunicacion del grupo. ^Se comunican los miembros del grupo de forma efec- 
tiva uno con otro? 

4. La organization del grupo. ^Esta organizado el equipo de tal forma que cada uno se 
siente valorado y satisfecho con su papel en el grupo? 

25.3.1 la composlclon del grupo 

Como se comento en la Seccion 25.2, muchos ingenieros de software estan motivados fun- 
damentalmente por su trabajo. Los grupos de desarrollo software, por tanto, estan frecuente- 
mente compuestos porpersonas que tienen sus ideas acerca de como deben resolverse los pro- 
blemas tecnicos. Este es un punto a partir del cual aparecen regularmente problemas: los 
estandares de interfaz se pasan por alto, los sistemas comienzan a redisenarse segun han sido 
codificados, embellecimientos innecesarios del programay otros mas. A serposible, se debe 
tratar de seleccionar un grupo de personas donde se eviten estos problemas. 

Un grupo que tiene personalidades complementarias puede trabajar mejor que un grupo se- 
leccionado exclusivamente por sus habilidades tecnicas. La gente motivada por su trabajo es 
la mas fuerte tecnicamente. Las personas orientadas a si mismas seran probablemente las me- 
jores para llevar adelante el trabajo hasta finalizar las tareas. La gente orientada a la interac- 
cion facilitara las comunicaciones con el grupo. Es particularmente importante tener gente 
orientada a la comunicacion en un grupo. A ellos les gusta hablar con la gente y pueden de- 
tectar tensiones y desacuerdos en etapas tempranas, por lo que tienen un gran impacto sobre 
el grupo. 

En el caso de estudio expuesto en laFigura 25.5, se muestracomo Alice, lagestoradel pro- 
yecto, ha tratado de crear un grupo con personalidades complementarias. Este grupo en par- 
ticular tiene una buena mezcla de personas orientadas a la interaccion y a las tareas, pero ya 
se ha indicado en la Figura 25.4 de como la personalidad orientada a si misma de Dorothy pue- 
de causar problemas. El papel de Fred con dedicacion parcial como experto del dominio pue- 
de ser tambien un problema aqui. El esta muy interesado en mejoras tecnicas, y puede no 
interactuar correctamente con otros miembros del grupo. El hecho de que el no sea siempre 
parte del equipo, implica que el no se identifica bien con las metas del equipo. 

Caso dt cstudlo 3: Composidon <M grupo 

En la creaci6n de un grupo para el desaooflo de un sistema de tecnotogia de asistencia, Alice es cons- 
dente de la importancia de la seleccion de miembros con personalidades complementarias. Mien- 
tras estaba entrevistando a la gente, trato de evaluar si los entrevistados orientados a la tarea, orien- 
tados a sf misrnos u orientados a la interaccion. Sinti6 que al principio eila era del tipo orientado a 
si mismo, y que d proyecto le pefmrtirfa ser reconocida como gestor senior y ser ascend ida. Por lo 
tanto, busco a una o dos personas orientadas a la interaccion y querfa individuos orientados a la ta- 
rea para completar el equipo. La evaluacion final a la que llego fue la siguiertte: 

Alke - orientada a sf misma 
Brian - orientado a la tarea 
Bob - orientado a la tarea 
Carol - orientada a la interaccion 
Dorothy - orientada a sf misma 
Ed - orientado a la interaccion 
Fred - orientado a la tarea 
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En algunas ocasiones es imposible elegir un grupo con personalidades complementarias. 
En este caso de estudio, el gestor de proyecto tiene el control del grupo, por lo que las metas 
individuales no trascienden a los objetivos organizacionales y del grupo. Este control es facil 
de lograr si todos los miembros participan en todas las etapas del proyecto. Las iniciativas in- 
dividuales son mas comunes cuando los miembros del grupo estan recibiendo instrucciones, 
sin ser conscientes de la parte que su tarea juega dentro del proyecto. 

Por ejemplo, supongamos que a un ingeniero se le da un disefio de un programa para co- 
dificary observa posibles mejoras de disefio. Si estas mejoras se implementan sin compren- 
der la razon del disefio original, podrian tener implicaciones adversas sobre otras partes del 
sistema. Si todos los miembros del grupo estan inmersos en el disefio desde el principio, en- 
tenderan las razones de las decisiones de disefio. Se identificaran con estas decisiones en lu- 
gar de oponerse a ellas. 

Un papel importante es el de lider del grupo. Este puede ser el responsable de proveer la 
direccion tecnicay gestion del proyecto. Los lideres del grupo deben conservarel trabajo ru- 
tinario del grupo, asegurandose de que la gente esta trabajando eficazmente y de la forma in- 
dicada por el gestor del proyecto en el planning. 

Los lideres son normalmente designados por el gestor general del proyecto. Sin embargo, 
el Hder designado puede no serun verdadero lider en el grupo, siendo mas preocupante cuan- 
to mas se aleje del liderazgo tecnico. Los miembros del grupo pueden ver a otro miembro 
como lider. Puede tratarse de un ingeniero mas competente tecnicamente, o puede serun mo- 
tivador mejor que el lider del grupo designado. 

A veces, resulta eficaz separar al lider tecnico de la administracion del proyecto. Las per- 
sonas que son competentes a nivel tecnico no siempre son los mejores administradores. El dar- 
le un rol administrativo puede reducir su valia dentro del grupo. Es mejor ayudarlo con un ad- 
ministrador que lo libere de las tareas rutinarias. 

Imponer a un lider que el grupo no quiera, normalmente causara tensiones. Los miembros 
del equipo no respetaran al lider y pueden perder la lealtad al grupo a favor de metas indivi- 
duales. Este es un problema concreto de las areas que cambian rapidamente, como es la in- 
genieriadel software, donde los nuevos miembros pueden estarmas actualizados y mejor pre- 
parados que los lideres experimentados del grupo. Algunas personas con experiencia pueden 
sentirse mal por la imposicion de un lider joven con nuevas ideas. 

25.3.2 Cohesion 

En un grupo cohesivo, los miembros piensan que es mas importante el grupo que los indivi- 
duos. Los miembros de un grupo cohesivo son leales al grupo. Se identifican con las metas 
del grupo y con los otros miembros del grupo. Intentan proteger al grupo, como entidad, de 
interferencias externas. Esto hace que el grupo sea fuerte y que sea capaz de sobrellevar pro- 
blemas y situaciones inesperadas. El grupo hara frente a los problemas mediante la ayuda y 
soporte mutuo. 

Las ventajas de un grupo cohesivo son las siguientes: 

1. Puede crearse un grupo que utilice estdndar de calidad. Como este estandar se esta- 
blece porconsenso, probablemente se observara mejor que si fuese extemo e impues- 
to al grupo. 

2. Los miembros de un grupo trabajan juntos. Las personas del grupo pueden aprender 
unas de otras. Las inhibiciones causadas por la ignorancia son minimizadas, asi como 

el aprendizaje mutuo los anima. 
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3 . Sepuede practicar la programacion sin ego puede ser practicada. Los pro gramas son 
reconocidos como propiedad del grupo, no de los individuos. 

Programacion sin ego (Weinberg. 1971) es un estilo de grupo de trabajo en el que los di- 
sefios, programas y otros documentos son considerados como una propiedad comun del gru- 
po en lugar de el individuo que los ha escrito. En la cultura de programacion sin ego, es mas 
probable que las personas ofrezcan su trabajo para inspeccion por otros miembros, para 
aceptar criticas y para trabajar con el grupo a fin de mejorar el programa. Los grupos co- 
hesivos son mejores porque todos los miembros sienten que comparten la responsabilidad 
del software. La idea de la programacion sin ego es fundamental en la programacion extre- 
ma (Beck, 2000), analizada en el Capitulo 17. En la programacion extrema, uno de los prin- 
cipios basicos es la mejora constante del codigo del sistema, independientemente de quien 
escribio el codigo. 

Ademas de la mejora de la calidad de los disenos, programas y documentos, la programa- 
cion sin ego tambien mejora las comunicaciones dentro del grupo. Esta permite discusiones 
desinhibidas sin considerar status, experiencia o sexo. Los miembros cooperan con otros 
miembros del equipo a traves del desarrollo del proyecto. Esto permite que los miembros del 
equipo trabaj en juntos y se sientan como parte de un equipo. 

La cohesion del grupo depende de muchos factores, entre los que se encuentran la cultura 
organizacional y las personalidades del grupo. Los administradores pueden fomentar la co- 
hesion de varias formas. Pueden organizar eventos sociales para los miembros del grupo y sus 
familias. Pueden tratarde establecerun sentido de identidad del grupo asignandole un nom- 
bre y estableciendo un territorio. Pueden estar involucrados en actividades en grupo como de- 
portes yjuegos. 

Sin embargo, una de las formas mas eficaces de promover la cohesion es asegurarque los 
miembros del grupo sean tratados como responsables y confiables y se les de acceso a toda 
la informacion. A menudo, los administradores sienten que no tienen que revelar cierta in- 
formacion a todo el grupo. Esto invariablemente crea un clima de desconfianza. El intercam- 
bio de informacion simple es una forma barata y eficiente de hacerque la gente sienta que es 
parte del grupo. 

Podemos ver un ejemplo de esto en el caso de estudio de la Figura 25.6. Alice realiza reu- 
niones informales regulares donde comenta al grupo lo que esta haciendo. Ella involucra a la 
gente en el desarrollo del producto, preguntandoles sobre las nuevas ideas derivadas de las ex- 

Caso de estudio \ El espirltu del equipo 

AHce, una gestora de proyectos experimentada, enUende la Importancla de ctear un grupo cohe- 
sive. Como el desarrollo del producto es nuevo, aprovecha la oporbinldad de Involucrar a todos 
los miembros del grupo en la especlflcaclon y el dlseno, obtenlendo oplnlones sobre la poslble 
tecnologia a apllcar con los miembros mayo res de sus famlllas, y trayendo a miembros de su fa- 
mllla al almueizo semanal del grupo. □ almuerzo del grupo es una oporbinldad para que todos 
los miembros del equipo se reunan Informalmente, ha Men de sus problemasy se conozcan unos 
a otros. 

En el almueizo, Alice dice a los miembros del grupo lo que sabe sobre notlclas organlzaclona- 
les, politlcas, estrateglas, etc Cada mlembro del equipo entonces resume lo que habla estado ha- 
ciendo y el grupo habla acerca de temas generates, como las nuevas Ideas de producto para sus 
parientes mayo res. 

Cada pocos meses, Alice organlza un «dia de vlsltantes» para el grupo, donde el equipo dedl- 
Hgura 25.6 ..>...». .. actuallzar tecnologia. Cada mlembro del equipo prepara una actuallzaclon sobre una 

Cohesion tecnologfa relevantey la presenta al grupo. Esta es una reunion fuera del lugar de trabajo, en un 

d e I grupo * • • • ■ •■••••■>• ■ . * . . p • . . . . programado para el dlalogo y la Interaction social. 
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periencias en su propia familia. Estas reuniones son un buen camino para fomentar la cohe- 
sion; las personas se relajan mientras se ayudan mutuamente a aprender las nuevas tecnolo- 
gias. 

Sin embargo, los grupos fuertes y cohesivos algunas veces padecen dos problemas: 

1. Resistencia irracional al cantblo de llderazgo. Si el Hder de un grupo cohesivo se 
reemplaza por alguien externo al grupo, los miembros del grupo se asocian en contra 
del nuevo Hder. Ademas, dichos miembros invierten tiempo al resistirse a los cambios 
propuestos por el nuevo Hder del grupo, lo que lleva a una perdida consecuente de la 
productividad. Por lo tanto, siempre que sea posible, es mejor designar a los nuevos 
Hderes de dentro de los grupos. 

2. Pensamiento de grupo. El pensamiento de grupo (Janis, 1972) es el nombre que reci- 
be la situacion en que las habilidades importantes de los miembros del grupo se co- 
rroen por la lealtad al grupo. La consideracion de alternativas se reemplaza por leal- 
tad a las normas y decisiones del grupo. Cualquierpropuesta favorecida por lamayoria 
del grupo se adopta sin consideracion de alternativas. 

Para evitar el pensamiento de grupo, se pueden organizar sesiones formales donde a los 
miembros del grupo se les pida que critiquen las decisiones. Se pueden introducir expertos 
para que revisen las decisiones del grupo. Las personas que argumentan, cuestionan y no res- 
petan el statu quo se designaran como miembros del grupo. Actuan como un abogado del dia- 
blo, constantemente cuestionan las decisiones del grupo, y asi fuerzan a otros miembros del 
grupo a razonar y evaluar sus actividades. 

25.3.3 Las comunlcaclones del grupo 

Es esencial que exista buena comunicacion entre los miembros de un grupo de desarrollo de 
software. Los miembros del grupo deben intercambiar informacion sobre el estado de su tra- 
bajo, las decisiones de diseno que se han tornado y los cambios necesarios para las nuevas de- 
cisiones. Las buenas comunicaciones tambien fortalecen la cohesion puesto que los miembros 
del grupo comprenden las motivaciones, fortalezas y debilidades de las personas del grupo. 
Algunos factores clave que influyen en la efectividad de las comunicaciones son: 

1. El tamaho del grupo. Si un grupo incrementa su tamafio, es mas dificil asegurar que 
todos los miembros se comuniquen unos con otros de forma efectiva. El numero de 
vinculos de comunicacion en una direccion es n * (n -1) donde n es el tamafio del gru- 
po. Como se puede ver, con un grupo de siete u ocho miembros, es muy posible que 
alguna persona raramente se comunique. Las diferencias de status entre los miembros 
del grupo implican que a menudo las comunicaciones son en una sola direccion. Los 
miembros de status mas alto tienden a dominar las comunicaciones con los miembros 
de status mas bajo, quienes a menudo rehuyen iniciar una conversacion o hacer obser- 
vaciones de critica. 

2. La estructura del grupo. Las personas en grupos estructurados informalmente se co- 
munican de forma mas efectiva que los grupos con una estructura jerarquica formal. 
En los gruposjerarquicos, las comunicaciones tienden a fluirhaciaarribayhacia aba- 
jo de lajerarquia. Las personas al mismo nivel no hablan unas con las otras. Este es 
un problema particular en un proyecto grande con varios grupos de desarrollo. Si las 
personas que trabajan en diferentes subsistemas solo se comunican con sus adminis- 
tradores, a menudo esto conduce a retrasos y malentendidos. 
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3. La composition del grupo. Si existen demasiadas personas en el grupo que tienen los 
mismos tipos de personalidad chocan entre ellas y las comunicaciones se inhiben. Por 
lo general, la comunicacion es mejor en grupos de ambos sexos (Marshall y Heslin. 
1975) que en grupos de un solo sexo. Las mujeres tienden a estar mas orientadas a la 
interaccion que los hombres y los miembros de un grupo de mujeres facilita y dirige 
la interaccion en el grupo. 

4. El entorno de trabajo flsico del grupo. L a organizacion del lugar de trabajo es un fac- 
tor importante para facilitar o inhibir las comunicaciones. Esto se analiza en la Sec- 
cion 25.3.5. 

25.3.4 La organizacion del grupo 

Los grupos pequenos de programacion, por lo general, se organizan de una forma mas infor- 
mal. El lider del grupo se involucra en el desarrollo de software con los otros miembros del 
grupo. De esta forma, emerge un lider tecnico qui en controla de forma efectiva la produccion 
de software. En un grupo informal, el trabajo a realizar se discute por el grupo como un todo 
y las tareas se asignan de acuerdo con la habilidad y experiencia. Los miembros mas experi- 
mentados del grupo realizan el disefio de sistemas de alto nivel, pero el diseno de bajo nivel 
es responsabilidad de los miembros a quienes se les asigna una tarea particular. 

Los grupos informales pueden ser muy exitosos, particularmente cuando la mayoria de los 
miembros del grupo son experimentados y competentes, El grupo funciona como una unidad 
democratica, que toma decisiones por consenso. Psicologicamente, esto mejora el espiritu del 
grupo con un incremento en la cohesion y el desempeno. Si un grupo se compone en su ma- 
yoria de miembros sin experiencia o incompetentes, informalmente pueden ser un estorbo. No 
existe una autoridad definida para dirigirse al grupo, lo que provoca una falta de coordinacion 
entre los miembros del grupo y, posiblemente, un desastre paraeste. 

Beck, en su libro sobre programacion extrema (Beck, 2000), describe una variante organiza- 
cional interesante de la organizacion democratica de grupos. En este enfoque, muchas decisiones 
que por lo general se ven como decisiones administrativas — como las decisiones de calendario — 
son desarrolladas por los miembros del grupo. Los programadores trabajan en parejas para des- 
arrollar el codigo y tomar una responsabilidad colectiva para los programas a desarrollar. 

Como se explica en el Capitulo 26, la habilidad individual influye de forma importante en 
la productividad del programador. Los mejores programadores pueden tener una productivi- 
dad 25 veces mayor que los peores programadores. Por lo tanto, lo mejor sera utilizar los me- 
jores programadores y darles lodo el apoyo necesario. 

Para utilizar de forma mas efectivaa los programadores conmucha habilidad, Baker(1972)y 
otros (Anon, 1974: Brooks. 1975) senalaron que los equipos deben construirse alrededor de un 
programador enjefe con muchas habilidades. El principio subyacente es que el personal con ha- 
bilidad y experiencia sea el responsable de todo el desarrollo del software. Ellos no deben estar 
implicados en cuestiones de rutina, y deben tener un buen apoyo tecnico y administrativo en su 
trabajo. Deben centrarse en el software a desarrollar y no involucrarse en reuniones extemas, 

Pero la organizacion del equipo tiene serios problemas porque sobrecarga al jefe de pro- 
gramadores y a su asistente. Otros miembros del equipo, a los cuales no se les ha dado la su- 
ficiente responsabilidad, comienzan a desmotivarse debido a que sienten que sus habilidades 
son infrautilizadas. 

A pesarde ello, el principio general de incrementar el equipo de programacion con espe- 
cialistas es una buena idea. Cuando se elija a los miembros del equipo, la eleccion puede cen- 
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trarse en gente con habilidades genericas como comunicaciones y resolucion de problemas, 
y luego se puede incorporar a expertos cuando el proyecto lo requiera. El uso de expertos es 
necesario, y los desarrolladores inexpertos tienen la oportunidad de aprender y desarrollar su 
pericia a medida que progresa el proyecto. 

25.3.5 Entomos de trabajo 

El lugar de trabajo tiene efectos importantes en el desempefio de las personas y en su satis- 
faccion en el trabajo. Los experimentos psicologicos han mostrado que el comportamiento se 
ve afectado por el tamano de la habitacion, el mobiliario, el equipo, la temperatura, la hume- 
dad, la luminosidad y la calidad de la luz, el ruido y el grado de privacidad disponible. El com- 
portamiento del grupo se ve afectado por la organizacion arquitectonica y los recursos de te- 
lecomunicaciones. Las comunicaciones dentro del grupo se ven afectadas por la arquitectura 
del edificio y la organizacion del lugar de trabajo. 

Existe un costo importante y real para proveer buenas condiciones de trabajo. Cuando las 
personas no estan felices con sus condiciones de trabajo, el movimiento de personal se incre- 
menta. Por lo tanto, tiene mucho mas costo el reclutamiento y lacapacitacion. Losproyectos 
de software se retrasan debido a la falta de personal cualificado (DeMarco y Lister, 1999). 

A menudo, el personal de desarrollo de software trabaja en areas y oficinas abiertas, algu- 
nas veces en cubiculos, y solo los administradores principales tienen oficinas individuales. 
McCue (1978) llevo a cabo un estudio que muestra que la arquitectura abierta que favorecia 
a muchas organizaciones no era popular ni productiva. Los factores del entorno mas impor- 
tantes que se identificaron en ese estudio de diseflo fueron: 

1 . Privacidad. Los programadores requieren un area donde se puedan concentrar y tra- 
bajar sin interrupcion. 

2. Repercusion del exterior. Las personas prefieren trabajar con luz natural y con una vis- 
ta del entorno exterior. 

3 . Personalization. Los individuos adoptan diferentes practicas de trabajo y tienen dife- 
rentes opiniones sobre ladecoracion. Lahabilidadparaarreglarel lugar de trabajo que 
permita llevar a cabo este y personalizar ese entorno es importante. 

En resumen, a las personas les gustan las oficinas individuales que puedan organizar como 
ellos quieran. Existen menos distracciones e interrupciones que en espacios de trabajo abier- 
tos. En las oficinas abiertas, a las personas se les niega la privacidad y un entorno de trabajo 
silencioso y se les limita la personalizacion de su lugar de trabajo. La concentracion es difi- 
ci 1 y el desempefio se degrada. 

Proveer oficinas individuales al personal de ingenieria de software puede tener una diferencia 
significativa en la productividad. DeMarco y Lister (1 985) compararon la productividad de los 
programadores en varios tipos de lugares de trabajo. Observaron que factores como la privacidad 
del lugar de trabajo y la habilidad para eliminar las interrupciones tenian un efecto importante. 
Los programadores que tenian buenas condiciones de trabajo eran dos veces mas productivos que 
los programadores con las mismas habilidades pero que tenian condiciones de trabajo peores. 

Los grupos de desarrollo necesitan areas donde todos los miembros del grupo se puedan 
reunir como grupo y discutir sus proyectos, tanto formal como informalmente. Las salas de 
juntas deben tener espacio para acomodar a todo el grupo con privacidad. Los requerimien- 
tos de privacidad individuales y los requerimientos de comunicacion del grupo son objetivos 
primordiales. McCue sugirio que agrupar oficinas individuales alrededorde lasgrandes salas 
de reunion (vease la Figura 25.7) era la mejor solucion. 
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Beck (2000) sugirio un modelo similar en su descripcion de un entorno para la programa- 
cion extrema. Sin embargo, sugiere mantener las areas abiertas, en las que todas las activida- 
des de programacion tienen lugar en un area comun, y cubiculos individuals para los miem- 
brosdel grupoque deseen trabajaraislados. Claramente, el requerimiento principal es proveer 
espacios individuates y espacios de grupo para que las personas puedan trabajar solas o en gru- 
po si es necesario. 

Este tipo de comunicacion ayuda a las personas a resolver sus problemas e intercambiar 
informacion de manera informal pero eficaz. Weinberg (Weinberg, 1971) cita un ejemplo 
anecdotico de como una organizacion quiso hacerque los programadores no desperdiciaran 
tiempo hablando entre si alrededorde unamaquinade cafe. Quitaron lamaquina, y de forma 
inmediata tuvieron un notable incremento de solicitudes para asistencia de programacion for- 
mal. Ademas de conversar alrededor de la maquina las personas resolvian sus problemas en- 
tre si. Esto ilustra que las companias necesitan lugares de reunion informales, asi como salas 
de conferencias formales. 

El caso de estudio de la Figura 25.8 muestra lo frecuente que es trabajar con restricciones 
impuestas por los edificios. No es posible adaptarlos o tener todo el espacio que se quisiera. 
En el ejemplo, Alice usa un despacho individual para trabajos donde se requiere concentra- 
cion y donde la gente puede discutir en privado que debe hacer. Los escritorios se comparten 



CaSO de estudb 5: Organizacion de la oficina 

Alice entiende la importancia de los entornos de trabajo pero su compartia nene un edificio de los 
ahos 70 que no puede ser adaptado a una estructura ideal. Le han asignado tres oficinas para su 
equipo - unapequena, individual y separada y dos grandesy juntas, con capacidad cada una para 
cuatro mesas—. Dos miembros del equipo (Carol y Brian) frecuentemente trabajan desde casa y 
Red, el experto en alarmas, solo trabaja con el equipo dos dias por semana. El equipo puede uti- 
lizar una sala de reuniones compartida con el resto de los grupos y cada planta del edificio tiene 
una zona de cafe para reuniones informales. 

En lugar de utilizar la oficina pequeha como su oficina personal, como lo hubiese hecho otro 
gestor, Alice decide que debe ser una zona tranquila donde el miembro del equipo que lo nece- 
site pueda trabajar sin distracciones. Efla designa una oficina para desarrollo con mesas para el 
hardware y para los papeles de los prototipos de las interfaces de usuario. Ademes, esta habita- 
cidn tiene un escritorio que normalmente usa Fred cuando esta trabajando con el equipo, pero 

Fisura 25 8 tambien es compartida por Carol y Brian cuando van a trabajar a la oficina. Alice comparte la otra 

Oreanizacion oficina con Bob, Dorothy y Ed. El edificio tiene una red wireless y todos los miembros tienen cal- 

, , - culadoras portatiles. 

de la oficina. 
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entre los miembros del equipo que no siempre trabajan en la oficina. Cada miembro del equi- 
po tiene una computadora portatil, y puede trabajar en cualquier lugar: en su escritorio, en la 
habitacion tranquila o en zonas comunes del edificio. 



25.4 El Modelo de Madurez de la Capacidad del Personal 

El Software Engineering Institute (SEI) en Estados Unidos lleva a cabo un programa a largo 
plazo, de mejora del proceso del software. Parte de este programa es el Modelo de Madurez 
de la Capacidad (CMM) para el proceso del software que se analiza en el Capitulo 28. Este 
se refiere a las mejores practicas en ingenieria de software. Para soportar este modelo tam- 
bien propusieron un Modelo de Madurez de la Capacidad del Personal (P-CMM) (Curtis et 
al., 2001). Este se puede utilizar como un marco de trabajo para mejorar la forma en la que 
una organizacion administra sus recursos humanos. 

De igual forma que el C M M , el P - C M M es un modelo de cinco niveles como se muestra 
en la Figura 25.9. Los cinco niveles son: 

1. Inicial Ad hoc. Seutilizan practicas informales de administracion de personal. 

2. Repetible. Establece las politicas para el desarrollo de la capacidad del personal. 



Metodos de mejora continua para 
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competencia organizational. 



lnnovaci6n continua de la fuena de trabajo 
Asesoramiento 
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Administraci6n cuantitativa del 
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,/Ciiltura partidpativa 
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Desarrollo de competencias 
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Figura 259 El Modelo de Madurez de la Capacidad del Personal. 
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3. Definido. Estandarizacionde las mejorespracticasde administracion de personal a lo 
largo de la organizacion. 

4. Administrado. Se establecen e introducen las metas de la administracion del personal. 

5. Optimizado. Existe un enfoque continuo en la mejora de la competencia individual y 
la motivacion de la fuerza de trabajo. 

Curtis et al. (Curtis et al. 2001) senalan que los objetivos estrategicos del P-CMM son: 

1. Mejorar la capacidad de las organizaciones de software incrementando la capacidad 
de su fuerza de trabajo. 

2. Asegurar que la capacidad de desarrollo de software sea un atributo de las organiza- 
ciones mas que de unos pocos individuos. 

3. Alinear la motivacion de los individuos con la de la organizacion. 

4. Retener los activos humanos (por ejemplo, personas con habilidades y conocimiento 
importantes) dentro de la organizacion. 

El P-CMM es una herramienta practica para mejorar la administracion de las personas en 
una organizacion ya que suministra un marco de trabajo para motivar, reconocer, estandarizar 
y mejorar las buenas practicas. Refuerza la necesidad de reconocer la importancia de las per- 
sonas como individuos y de desarrollar sus capacidades. Por supuesto, la aplicacion comple- 
ta de este modelo es muy extensa y probablemente innecesaria para muchas organizaciones. 
Sin embargo, el modelo es una guia de ayuda que puede conducir a mejoras importantes en 
la capacidad de las organizaciones para producir software de alta calidad. 
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LECTURAS ADICIONALES 

A Handbook of Software and Systems Engineering: Empirical Observations, Laws and Theories. Este libro trata de 
conclusiones empiricas, hipdtesis y teorias relevantes para la ingeniena del software. El Capitulo 10 estudia las ha- 
bilidades, motivacion y satisfaccidn del usuario y habla de teorias de psicologia que refuerza estos temas. (A. An- 
dres y D. Rombach, 2003, Addison-Wesley.) 

Software Management, 6th ed. Este es un tutorial de IEEE que tiene varios articulos sobre como dirigiry motivar a 
las personas. (D. j. Reifer, 2002, Wiley-IEEE Press.) 

The People Capability Maturity Model: Guidelines for Improving the Workforce. Este libro hace una description fa- 
cilmente comprensible del modelo P-CMM, incluyendo una gma para mejorar las capacidades individuales, desa- 
rrollar una estructura organizacional fuerte, medir el rendimiento y crear una organizacion flexible de trabajo. (8. 
Curtis et ai, 2001, Addison-Wesley.) 

Peopleware: Productive Projects and Teams, 2nd ed. Este es un libro clasico sobre la importancia de tratar adecua- 
damente a las personas cuando gestionamos proyectos de software. Es facil de leer y es uno de los pocos libros don- 
de se reconoce la importancia del lugar en el que se trabaja. Se recomienda ampliamente. (T. DeMarco y T. Lister, 
1999, Dorset House.) 



EJERCICIOS Til 

25.1 Explique por que la coherencia, respeto, inclusion y franqueza son factores que contribuyen eficazmente 
en la gestidn de personal. 

252 iQue factores deben tenerse en cuenta a la hora de seleccionar el personal para un proyecto software? Ra- 
zone la respuestaysugiera cuales de estas seran mas importantes en laseleccidnde personal para el des- 
arrollo de un sistema empotrado en tiempo real a fin de desarrollar un controlador para un ojo de una ma- 
quina de cirugia. 

25.3 Desarrolle el caso de estudio del ejemplo sobre motivacion de la Figura 25.4 incluyendo actividades ge- 
nerates que Atice podria incorporar para asegurarse de que otros miembros del equipo sigan motivados. 

25.4 Explique por que mantener a los miembros del equipo informados acerca del progreso y de las decisiones 
tecnicas del proyecto puede mejorar la cohesion del grupo. 

25.5 Explique loqueentiendepor«pensamientoengrupo». Describa los peligros de este fendmenoy explique 
como pueden evitarse. 

25.6 Explique que problemas pueden aparecer en un equipo de programacidn extrema donde muchas decisio- 
nes de gestidn son tomadas por los propios miembros del equipo. 

25.7 iPor que las oficinas de plan abierto y oficinas compartidas son a veces menos recomendables que las in- 
dividuales para el desarrollo de software? <,En que circunstancias piensa que los entornos abiertos pue- 
den ser mejores? 

25.8 iPor que es P-CMM un marco eficaz para la mejora de gestidn de personal en una organizacion? Sugiera 
como puede ser modificado para ser usado en pequehascomparnas. 

25.9 iDeben los gestores hacerse amigos y mezclarse socialmente con los miembros mas jdvenes de su equi- 
po de trabajo? 

25.10 £Es etico suministrar las respuestas que el examinador desea ver mas que decir lo que uno siente cuando 
se llevan a cabo pruebas psicoldgicas? 
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Estimation de costes 
del software 



Objetivos 

El objetivo de este capitulo es introducir las tecnicas de estimacion 
de coste y esfiierzo requeridos para el desarrollo de software. 
Cuando termine de leer este capitulo: 

• comprendera los fundamentos que determinan el coste y 
esfuerzo del software as! como la compleja relacion existente 
entre estos; 

• conocera tres de las metricas que se utilizan para la valoracion 
de laproductividad; 

• apreciara las diversas tecnicas que se utilizan en la estimacion 
de los costes y en la planificacion de los proyectos software; 

• comprendera los principios del modelo de COCOMO II para la 
estimacion algoritmica de costes. 

Contenidos 

26.1 Productividad 

26.2 Tecnicas de estimacion 

26.3 Modelado algoritmico de costes 

26.4 Duracion y personal del proyecto 
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En el Capitulo 5, se introdujo el proceso de planificacion de proyectos. Durante este proceso, 
un proyecto se divide en varias actividades que se llevan a cabo en paralelo o de forma se- 
cuencial. El analisis previo sobre la planificacion de proyectos se centro en la forma de re- 
presentar las actividades, su dependencia y la asignacion de personal para llevar a cabo estas 
tareas. En este capitulo, se volvera al problema de las estimaciones asociadas al esfuerzo y al 
tiempo con las actividades identificadas en el proyecto. Cuando estimamos, debemos res- 
ponder a las siguientes preguntas: 

1. ^Cuanto esfuerzo se requiere para completar una actividad? 

2. ^.Cuanto tiempo, de calendario, se necesita para completar una actividad? 

3. ^,Cual es el coste total de una actividad? 

La estimacion y la creacion del calendario del proyecto se llevan a cabo de forma conjunta. 
Sin embargo, en las primeras etapas del proyecto se requieren algunas estimaciones de costes, 
antes de que se haga la planificacion detallada. Estas estimaciones son necesarias para estable- 
cer un presupuesto para el proyecto o para asignar un precio para el software de un cliente. 

Existen tres parametros involucrados en el calculo del coste total de un proyecto de desa- 
rrollo de software. 

• Los costes hardware y software, incluyendo el mantenimiento. 

• Los costes de viajes y capacitacion. 

• Los costes de esfuerzo (los costes correspondientes al pago de los ingenieros). 

Para muchos proyectos, los costes dominantes son los costes de esfuerzo. Las computa- 
doras con potencia suficiente para desarrollar software son relativamente baratas. Aunque los 
costes de viajes pueden ser importantes si un proyecto se desarrolla en sitios distintos, son una 
pequena parte comparados con los costes de esfuerzo. Ademas, el uso de correo electronico, 
sitios web compartidos y videoconferencias reducen el coste de los viajes y del tiempo hasta 
en un 50%. 

Los costes de esfuerzo no solo son los salarios de los ingenieros que intervienen en el pro- 
yecto. Las organizaciones calculan los costes de esfuerzo en funcion de los costes totales, don- 
de se tiene en cuenta el coste total para hacer funcionar la organizacion y dividen este entre 
el numero de personas productivas. Por lo tanto, los siguientes costes son parte de los costes 
totales: 

1 . Costes de proveer, aclimatar e iluminar las oficinas. 

2. Los costes del personal de apoyo como administrativos, secretarias, limpiadores y tec- 
nicos. 

3. Los costes de redes y las comunicaciones. 

4. Los costes de los recursos centralizados como las bibliotecas, los recursos recreativos, etc. 

5. Los costes de seguridad social, pensiones, seguros privados, etc. 

Este factor de sobrecarga normalmente es el doble del salario de un ingeniero software, de- 
pendiendo del tamaflo de la organizacion y sus sobrecargas asociadas. Por lo tanto, si a un in- 
geniero de software se le pagan 90.000 $ al ano, el coste total de la organizaciones de 180.000 
S por ano o 15.000 $ por mes. 

Una vez que se inicia el proyecto, los gestores deben actualizar regularmente sus estima- 
ciones de tiempo y de coste. Esto ayuda en el proceso de planificacion y en el uso efectivo de 
los recursos. Si los gastos actuales son significativamente mayores que los estimados, el ges- 
tor del proyecto debera tomar alguna decision. Esto implica que puede incorporar recursos 
adicionales al proyecto o modificar los trabajos a realizar. 
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Oportunidad de mercado 


Una organizacion de desarrollo podrfa ofertar un bajo predo debkJo a que desea conse- 
guir cuote de mercado. 

Aceptar un benendo bajo en un proyecto podrfa darle la oportunidad de obteiw mas be- 
rtefkios posteriormente. La experiencia obtenida le permite desanollar nuevos productos. 


Incertidumbre en la 
estimation de costes 


Si una organizacion esti insegura de su coste estimado, puede incremerrtar su precio por 
end ma del benefkio normal para cubrir aiguna contingenda. 


Termtnos contractuaies 


Un cKerrte puede estar dispuesto a permitir que el desarroUador retenga la prapiedad del 
c6digo fuente y que reutilke el codigo en otros proyectos. Por to tanto, el predo podrfa ser 
menof que si el codigo fuente del software se le entregara al ctiente. 


Voiatilidad de los requerimtentos 


Si es probable que los requerimientos cambien, una organizacion puede redudr los pre- 
cios para ganar un contrato. Despues de que el contratose leasigne, se cargan precios al- 
tos a los cambios en los requerimientos. 


Salud financiera 


los desarroHadores en drficu Hades finanderas podrian bajar sus precios para obtener un 
contrato. Es mejor tener benefidos mas bajos de los norrnales o mduso quebrar antes de 
quedarfuera de los negocios. 



Figura 26.1 Factores que afectan al precio del software. 



La estimacion del software debe realizarse de forma objetiva e intentando predecir lo me- 
jor posible el coste de desarrollo del software. Si el coste del proyecto se calcula dentro de un 
presupuesto para un cliente, entonces tendremos que decidir como se relacionan ambos con- 
ceptos. De forma clasica, el precio es simplemente el coste mas el beneficio. Sin embargo, la 
relacion entre el coste del proyecto y su precio no es tan simple. 

Al asignar un precio al software debemos tener en cuenta consideraciones organizaciona- 
les, economicas, politicas y de negocios. En la Figura 26,1 se muestran los factores que se de- 
ben tener en cuenta. Por lo tanto, no existe una relacion sencilla entre el precio del software 
que se le da al cliente y los costes de desarrollo. Debido a las consideraciones organizaciona- 
les involucradas, asignar el precio del proyecto por lo general le concierne al administrador 
principal de la organizacion, asi como a los gestores de software. 

Por ejemplo, una pequena compafiia de desarrollo software para empresas de carburantes 
tiene 10 ingenieros aprincipios de afto, pero para los contratos que tiene actualmente solo ne- 
cesita cinco miembros del equipo de desarrollo. Sin embargo, su oferta para un contrato de 
larga duracion con la principal empresa de carburantes requiere 30 personas/afio a lo largo de 
dos anos. El proyecto no puede empezar hasta dentro de 12 meses, pero, si se otorga, trans- 
formara las finanzas de la pequena empresa. La compafiia software tiene la oportunidad de 
comenzar un proyecto que requiere seis personas y que debe estar completado en 10 meses. 
Los costes (incluida la sobrecarga) son estimados en 1,2 millones de dolares. Sin embargo, 
para mejorar su posicion respecto a los competidores, la compafiia software ofrece un precio 
de 0,8 millones. Esto significa que, apesar de perder dinero en este contrato, la organizacion 
puede retener al personal experto para futuros proyectos mas rentables. 

26.1 Productividad 

La productividad en una empresa manufacturera se mide dividiendo el numero de unidades 
producidas entre el numero de personas/hora requeridas para producirlas. Sin embargo, para 
cualquier problema de software, existen muchas soluciones diferentes con distintas caracte- 
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risticas. Una solucion podria ejecutarse de forma mas eficiente mientras otra podria ser mas 
legible y facil de mantener. Cuando se producen soluciones con distintas caracteristicas, no 
tiene sentido comparar las tasas de produccion. 

Sin embargo, los administradores tienen que estimar la productividad de los ingenieros en 
el proceso de desarrollo software. Estas estimaciones son necesarias para la estimacion del 
proyecto y para valorar si los procesos o las mejoras tecnologicas son efectivas. Por lo gene- 
ral, estas estimaciones de productividad se basan en mediralguno de los atributos del software 
y dividir el resultado entre el esfuerzo total requerido para el desarrollo. Existen dos tipos de 
medidas utilizadas: 

1 . Medidas relacionadas con el tamaho. Esta se relacionan con el tamaiio de la salida de 
alguna actividad. La medida mas comiin relacionada con el tamafio son las lineas de co- 
digo fuente entregadas. Otras medidas que se utilizan son el numero de instrucciones de 
codigo objeto entregado o el numero de paginas de la documentacion del sistema. 

2. Medidas relacionadas con la funcion. Estas se relacionan con la funcionalidad total 
del software entregado. La productividad se expresa segun la cantidad de funcionali- 
dad util producida en un tiempo dado. Los puntos de funcion y los puntos objeto son 
las medidas mas conocidas de este tipo. 

Las lineas de codigo fuente por programador/mes son una metrica ampliamente utilizada 
en la medida de la productividad. Esta se calcula contando el numero total de lineas de codi- 
go fuente que se entrega. La cuenta se divide entre el tiempo total de programadores/mes re- 
queridos para completar el proyecto. Por lo tanto, este tiempo incluye el tiempo requerido para 
el analisis y disefio, codificacion, pruebas y documentacion. 

Este enfoque se desarrollo cuando muchos de los programas estaban en FORTRAN, len- 
guaje ensambladoro COBOL. Entonces, los programas se tecleaban en tarjetas, con una ins- 
truccion en cada tarjeta. El numero de lineas de codigo era facil de calcular: correspondia al 
numero de tarjetas. Sin embargo, los programas en lenguajes como Java o C++ consisten en 
declaraciones, instrucciones ejecutables y comentarios. Incluyen macroinstrucciones que ocu- 
pan varias lineas de codigo. Existe mas deuna instruccion por linea. Porlo tanto, no hay una 
relacion sencilla entre las instrucciones de programa y las lineas de un listado. 

Comparar la productividad de los diferentes lenguajes de programacion tambien da im- 
presiones engaflosas de la productividad del programador. Cuanto mas expresivo sea un len- 
guaje de programacion, mas baja sera la productividad aparente. Estaanomalia surge debido 
a que todas las actividades de desarrollo de software se consideran de forma conjunta cuan- 
do se calcula la productividad, pero la metrica utilizada solo tiene en cuenta los procesos de 
programacion. Por lo tanto, si un lenguaje requiere mas lineas que otro para implementar la 
misma funcionalidad, la estimacion de la productividad puede ser totalmente erronea. 

Por ejemplo, consideremos un sistema que podria codificarse con 5.000 lineas de codigo 
ensambladoro 1.500 lineas de codigo de lenguaje de alto nivel. En la Figura 26.2 se muestra 
el tiempo de desarrollo para las diversas fases. El programador de ensamblador tiene una pro- 
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ductividad de 714 lineas/mes y el programador de alto nivel menos de la mitad de estas, 300 
lineas/mes. Asi los costes de desarrollo para un sistema en C son menores y el sistema se desa- 
rrolla en menos tiempo. 

Una alternativa a la utilizacion del tamafio del codigo como atributo de estimacion es uti- 
lizar alguna medida de la funcionalidad del producto. Esto evitara la anomalia anterior pues- 
to que la funcionalidad es independiente del lenguaje de programacion. MacDonell (MacDo- 
nell, 1994) describe brevemente y compara varias medidas diferentes basadas en la 
funcionalidad. Lamas conocidade estas medidas son lospuntosde funcion. Estos fueronpro- 
puestos por Albrecht (Albrecht, 1979) y refinado por Albrecht y Gaffney (Albrecht y Gaff- 
ney, 1 983). Garmus y Herron {Garmus y Herron, 2000) describen el uso practico de los pun- 
tos de funcion en proyectos software. 

La productividad se expresa como el numero de puntos de funcion que son implementa- 
dos por persona/mes. Un punto de funcion no es una caracteristica simple sino que es una 
combinacion de caracteristicas del programa. El numero total de puntos de funcion en un pro- 
grama se calcula midiendo o estimando las siguientes caracteristicas del programa: 

• Entradas y salidas externas. 

• Interacciones con el usuario. 

• Interfaces extemas. 

• Archivosutilizados por el sistema. 

Obviamente, algunas entradas, salidas e interacciones son mas complejas que otras y se tar- 
da mas en implementarlas. Las metricas de puntos de funcion tienen esto en cuenta multipli- 
cando las estimaciones de puntos de funcion iniciales porun factor de complejidad. Se debe- 
ria calcular cada una de estas cuestiones y asignarles un valor de peso, que varia desde 3 (para 
entradas extemas simples) hasta 15 (para ficheros internos complejos). Pueden tomarse los pe- 
sos propuestos por Albretcht u otros obtenidos mediante la propia experiencia. 

Se pueden calcular los llamados puntos de funcion «no ajustados» (UFC) multiplicando 
los contadores iniciales por los pesos estimados y sumando todos los valores. 

UFC = "(numero de elementos de un tipo) x (peso) 

Ahora se pueden modificar estos puntos de funcion «no ajustados» a traves de factores de 
complejidad relativos a la complejidad del sistema como un todo. Esto introducira en la esti- 
macion el grado de proceso distribuido, la cantidad de reutilizacion y el rendimiento, entre 
otras cosas. Los puntos de funcion «no ajustados» se multiplican por estos factores de com- 
plejidad del proyecto y producen los puntos de funcion finales para todo el sistema. 

Symons (Symons, 1988) observo que la naturaleza subjetiva de la complejidad de las es- 
timaciones implicaba que la contabilizacion de puntos de funcion en un programa depende de 
la persona que hace la estimacion. Diferentes personas tienen nociones diferentes de com- 
plejidad. Existe una amplia variedad de contabilizacion de puntos de funcion, dependiendo 
del estimador. Por esta razon, existen versiones que difieren acerca del valor de los puntos de 
funcion dependiendo deljuicio del estimador y del tipo de sistema a desarrollar. Ademas, los 
puntos de funcion estan predispuestos para ser utilizados en sistemas de proceso de datos don- 
de dominan las operaciones de entrada y salida. Es mas duro estimar a traves de puntos de fun- 
cion sistemas dirigidos por eventos. Por esta razon, algunas personas piensan que los puntos 
de funcion no son muy utiles para medir la productividad software (Furey y Kitchenham, 
1997; Armour, 2002). Sin embargo, los usuarios de los puntos de funcion argumentan que, a 
pesarde sus defectos, estos son efectivos en situacionespracticas (Banker I Z/ . , 1993; Gar- 
mus y Herron, 2000). 



566 CAPITULO 26 • Estimacion de costes del software 



Los puntos objeto (Banker et ah, 1994) son una alternativa a lospuntos de funcion. Estos 
pueden ser utilizados en lenguajes 4GL y en lenguajes basados en script. Los puntos objeto 
no son las clases que pueden ser producidas cuando utilizamos un desarrollo orientado a ob- 
jetos. El numero de puntos objeto en un programa es una estimacion de: 

1 . El numero de pantallas independientes que se despliegan. Las pantallas sencillas cuen- 
tan como 1 punto objeto, las pantallas moderadamente complejas cuentan como 2 y 
las pantallas muy complejas cuentan como 3 puntos objeto. 

2. El numero de informes que se producen. Los informes simples cuentan como 2 pun- 
tos objeto, los informes moderadamente complejos cuentan como 5, y los informes 
que son dificiles de producir cuentan como 8 puntos objeto. 

3. El numero de modulos en lenguajes imperativos como Java o C++ que deben ser des- 
arrollados para complementar el codigo de programacion de la base de datos se con- 
tabilizaracomo 10 puntos objeto. 

Los puntos objeto se utilizan en el modelo de estimacion COCOMO II (donde se denomi- 
nan puntos de aplicacion), que se anlizaramas adelante enestecapitulo. La ventajade lospun- 
tos de objeto sobre los puntos de funcion es que pueden ser facilmente estimados a partir de 
la especificacion de alto nivel. Para el calculo de los puntos objeto solo intervienen las pan- 
tallas, los informes y los modulos escritos en lenguajes de programacion convencionales. No 
se tienen en cuenta detalles de implementacion, y la estimacion del factor de complejidad es 
mucho mas sencilla. 

Si se utilizan los puntos de funcion o los puntos objeto, entonces se pueden estimar en 
las primeras etapas del proceso de desarrollo. Las estimaciones de estos parametros se pue- 
den hacer tan pronto como se disenen las interacciones extemas del sistema. En esta etapa, 
es muy dificil producir una estimacion precisa del tamafio del programa en lineas de codi- 
go fuente. 

El calculo de los puntos de funcion y puntos objeto puede utilizarse junto con modelos de 
estimacion de lineas de codigo . El numero de puntos de funcion se emplea para estimar el ta- 
mafio final del codigo . Utilizando el analisis de datos historicos, se puede estimar el prome- 
dio de lineas de codigo, A VC , para implementarun punto de funcion en un lenguaje particu- 
lar. Los valores de AVC varian desde 200-300 LOC/FP en lenguaje ensamblador hasta 2-40 
en un lenguaje de programacion debase de datos como SQL. El tamafio estimado del codigo 
para una nueva aplicacion se calcula como se muestra a continuacion: 

Tamafio del codigo = AVC x Numero de puntos de funcion 

La productividad de los ingenieros que trabajan en una organizacion se ve afectada por 
varios factores. Algunos de los mas importantes se resumen en la Figura 26.3. Sin embar- 
go, las diferencias individuales en la habilidad son mas importantes que cualquiera de es- 
tos factores. En una primera valoracion de la productividad, Sackman y otros (Sackman et 
au, 1968) comprobaron que algunos programadores eran diez veces mas productivos que 
otros. La experiencia demuestra que esto sigue siendo cierto. Los equipos grandes tienen 
una mezclade habilidades, por lo que tienen una productividad «promedio». Sin embargo, 
en los equipos pequenos la productividad total depende en gran medida de las aptitudes y 
habilidades individuales. 

La productividad del desarrollo software varia notablemente a traves de distintos domi- 
nios de la aplicacion y organizaciones. Para sistema empotrados, grandes y complejos, la 
productividad es muy baja, alrededorde 30 LOC/pm. Para aplicaciones bien entendidas, es- 
critas en un lenguaje como Java, esta puede llegara serde 900 LOC/pm. Cuando se mide en 
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Experience en el dominio 
de la apfkacion 


Conooer el dominio de la aphcadbn es esendej pm el dtsandb efecbV»d*J nuttmn. 
lot ingenjeros oue ya conocen un dominio son pfobaMeffiente lot Rtas ptvductjvDa. 


Calidad del proceso 


Et proceso de desarrollo utiliiado puede tener un etecto Importante en to prodartMdld. 
Esto se expondra en el Capftulo 28. 


Tamefto del proyecto 


Cuando una proyecto es mas grandc, se requiem maa towpo pafilat aaniiWcaClonai del 
eourpo. Se dispone de menos tiempo para d desarrolo, pot to quota producnwWad indi- 
vidual deminuye. 


Apoyo tecnoJdgico 
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O proceso de desarrollo utillzado puede tener un efecto Importante en la productMdad. 
Esto se expondra en el Capltailo 28. 

Cuando una provecto es mas grande, se recaden mas tlelnpe 
equlpo. Se dispone q^merwsuempo parad 
vldual dnmmuye. 

La producHvldad se puede mejorar si se Uene un buen apoyo tecnologlco como el de he- 
rramlerttas CASE, de sistemas de gestlon de corn "waaones, etc. 

Como se explica en el Capltailo 25, un entomo da trabajo sflenoosc con amas de trabajo 
prtvado contrlbuye a mejorar la productMdad. 
Flgura 26.3 Factores que afectan a la productividad de ingenieria de software. 

terminos de puntos objeto, Boehm y otros (Boehm et ai, 1995) senalan que la productivi- 
dad varia desde 4 puntos objeto por mes hasta 50 por mes, dependiendo del tipo de aplica- 
cion, las herramientas de apoyo y la capacidad del programador. El problema de estas me- 
didas que expresan el volumen producido en un periodo de tiempo es que no tienen en 
cuenta las caracteristicas no funcionales del software como la Fiabilidady el mantenimien- 
to. Implican que mas siempre significa mejor. Beck (Beck, 2000), en su estudio sobre pro- 
gramacion extrema, establece un excelente punto acerca de la estimacion. Si la aproxima- 
cion esta basada en la simplificacion y optimizacion del codigo, entonces el recuento de 
numero de lineas de codigo no es relevante. 

Ademas, estas medidas no tienen en cuenta la posibilidad de reutilizar el software produ- 
cido, utilizar generadores de codigo u otras herramientas que nos ayuden en la creacion de 
software. Lo que realmente quieren estimar es el coste de crear un sistema particular donde 
se han definido la funcionalidad, la calidad, el rendimiento, el mantenimiento, etc. Esto solo 
se relaciona de manera indirecta con medidas tangibles como el tamano del sistema. 

El gestor no debe usar las medidas de productividad parajuzgar las habilidades de los in- 
genieros de su equipo. Si lo hace, los ingenieros deben estar comprometidos con la calidad 
con el finde ser mas «productivos». Este es el caso en el que los programadores «menos pro- 
ductivos» producen codigo mas fiable que es mas facil de comprender y mas barato de man- 

s medidas de productividad como una informacion par- 
productividad del programador. Tendra que considerar otra informacion, como 
la calidad de los programas que se producen. 

No hay una forma simple de hacer una estimacion precisa del esfuerzo requerido para des- 
arrollarun sistema de software. Las estimaciones iniciales se hacen partiendo de ladefinicion 
de requerimientos de usuario de alto nivel. El software tiene que ejecutarse en computadoras 
poco familiares y utilizar nuevas tecnologias de desarrollo. Probablemente no se conozcan las 
personas involucradas en el proyecto y sus habilidades. Todos estos factores significan que en 
una primera etapa del proyecto es dificil producir una estimacion precisa de los costes de des- 
arrollo del sistema. 
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Mas aun, existe una dificultad fundamental para valorar la precision de los diferentes en- 
foques de las tecnicas de estimacion de costes. Por lo general, las estimaciones de costes se 
cumplenpor supropia natural eza. La estimacion seutiliza para definir el presupuesto del pro- 
yecto y el producto se ajusta para que las cifras del presupuesto se cumplan. No se conocen 
informes de experimentos de control sobre costes de proyectos donde los costes estimados no 
se utilicen para ajustar el experimento. Un experimento de control no deberia revelar la esti- 
macion del coste al administrador del proyecto. Los costes reales tendrian que compararse con 
los estimados del proyecto. Sin embargo, realizarun experimento de este tipo seria imposi- 
ble, debido a los altos costes que conlleva y al numero de variables que no pueden ser con- 
troladas. 

A pesar de esto, las organizaciones necesitan hacer estimaciones de esfuerzo y costes. Para 
hacerlo, se utilizan una o mas tecnicas de las descritas en la Figura 26.4 (Boehm, 1981). To- 
das estas tecnicas se basan en la experiencia de los gestores de proyectos, los cuales usan sus 
conocimientos en proyectos previos para llegar a una estimacion de los recursos necesarios 
en un proyecto. Sin embargo, puede haber diferencias importantes entre proyectos pasados y 
futures. En los diez ultimos afios se han introducido muchas tecnicas y metodos nuevos de 
desarrollo. Algunos de los cambios que pueden afectar a las estimaciones basadas en la ex- 
periencia son: 

1 . Sistemas orientados a objetos y distribuidos en lugar de sistemas centralizados (main- 
frames). 

2. Usodeserviciosweb. 

3. Uso de ERP o sistemas basados en bases de datos. 

4. Uso de paquetes software ajenos en lugar de desarrollar lodo el software propio. 

5. Desarrollo reutilizando componentes en lugar de hacer todo un desarrollo nuevo. 

6. Desarrollo utilizando lenguajes script tales como T C L o Perl (Ousterhout, 1998). 

7. El uso de herramientas C A S E o generadores de programas mas que desarrollo de soft- 
ware no asistido. 

Si los gestores del proyecto no han trabajado con estas tecnicas, su experiencia previa no 
les ayudara a estimar los costes del software. Esto hace que sea mas dificil producir costes y 
estimaciones de agenda precisos. 

Los enfoques para la estimacion de costes de la Figura 26.4 se pueden abordar utilizando 
un enfoque descendente o ascendente. Un enfoque descendente se inicia a nivel de sistema. 
Se comienza examinando la funcionalidad total del producto y su interaccion con las subfun- 
cionalidades. Los costes a nivel de sistema tienen en cuenta actividades tales como la inte- 
gracion, configuracion, gestion y documentacion. 

El enfoque ascendente, por el contrario, se inicia a nivel de componentes. El sistema se di- 
vide en componentes y se calcula el esfuerzo requerido para desarrollar cada uno de los com- 
ponentes. Estos costes se suman para dar el esfuerzo requerido del desarrollo del sistema com- 
plete. 

Las desventajas del enfoque descendente son las ventajas del ascendente, y viceversa. La 
estimacion descendente subestima los costes de resolverproblemas tecnicos dificiles asocia- 
dos a componentes especificos como las interfaces de hardware no estandares. No existejus- 
tificacion detallada de la estimacion que se produce. En cambio, la estimacion ascendente pro- 
duce tal justificacion y considera cada componente. Sin embargo, este enfoque tiende a 
subestimar los costes de las actividades de sistema tales como la integracion. La estimacion 
ascendente tambien es mas costosa. Debe de haber un diseno inicial del sistema para identi- 
ficar los componentes a evaluar. 
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Modelado algorftmico de costes 


Se desarrotla un modelo utilizando information historica de costes que retadona alguna me- 
trtea de software (por lo general, su tamaflo) con el coste del proyecto. Se hace una esti- 
macion de esa metrica y el modelo predke d esfuerzo requerido. 


Juido experto 


Se consuftan varies expertos en las tecnicas de desarroflo de software propuestas y en el do- 
minio de la apWcacidn. Cada uno de ellos est ma el coste del proyecto. Estas estimaciones se 
com pa ran y $e discuten. El proceso de estimadctn se rtera hasta que se Hega a un consensa 


Estimation por analogia 


Esta tecnica es aplicable cuando otros proyectos en el mismo dominio de aplkad6n se han 
compJetado. Se estima el coste de un nuevo proyecto por analogia con estos proyectos com- 
pletados. Myers (Myers, 1989) da una description muy clara de este enfoque. 


Ley de Parkinson 


La Ley de Parkinson establece que el trabajo se extiende para llenar el tiempo disponible. 
El coste se determinara por los recursos disponibles mas que por los objetivos logrados. Si 
el software se tiene que entregar en 12 meses y se dispone de cmco personas, el esfuerzo 
requerido se estima en 60 personas/mes. 


Pricing to win 


El coste del software se estima a partir de a lo que el dientc esta dispuesto a pa gar por el 
proyecto. El esfuerzo estimado depende del presupuesto del dterrte y no de la fundonali- 
dad del software. 


Juicio experto 
Estimacion por analogia 
Ley de Parkinson 

Priring to win 


Se consuitan varios expertos en las tecnicas de desarrollo de software propuestas y en el do- 
minio de la aplicacion. Cada uno de ellos estima el coste del proyecto. Estas estimaciones se 
comparany se discuten. El proceso de estimacion se itera hasta que se Uega a un consenso. 
Esta tecnica es aplicable cuando otros proyectos en el mismo dominio de aplicacion se han 
completada Se estima el coste de un nuevo proyecto por analogia con estos proyectos com- 
pletados. Myers (Myers, 1989) da una descripcion muy clara de este enfoque. 
La Ley de Parkinson establece que el trabajo se extiende para llenar el tiempo disponible. 
El coste se determinara por los recursos disponibles mas que por los objetivos logrados. Si 
el software se tiene que entregar en 12 meses y se dispone de cinco personas, el esfuerzo 
requerido se estima en 60 personas/mes. 

El coste del software se estima a partir de a lo que el diente esta dispuesto a pagar por el 
proyecto. El esfuerzo estimado depende del presupuesto del cliente y no de la funcionali- 
dad del software. 

Figura 26.4 Tecnicas de estimacion de costes. 



Cada tecnica de estimacion tiene sus ventajase inconvenientes. Cada una utilizadiferente 
informacion acerca del proyecto y del equipo de desarrollo; por lo tanto, si se utiliza unica- 
mente un modelo y la informacion no es precisa, la estimacion final sera erronea. Para pro- 
yectos grandes, se deben utilizar varias tecnicas de estimacion de costes y comparar sus re- 
sultados. Si estos predicen costes totalmente diferentes, probablemente no tenga informacion 
suficiente acerca del producto o del proceso de desarrollo. Se debe buscarmas informacion 
del producto, del proceso y del equipo y repetir el proceso de calculo de costes hasta que la 
estimacion converja. 

Estas tecnicas de estimacion son aplicables cuando existe un documento de especificacion 
de requerimientos para el sistema. Este debe definir todos los requerimientos de usuario y de 
sistema. Se pueden hacer estimaciones razonables de la funcionalidad del sistema a desarro- 
llar. En general, los proyectos grandes de ingenieria de sistemas tendran tal documento de re- 
querimientos. 

Sin embargo, en muchos casos, los costes de muchos proyectos deberan serestimados uti- 
lizando solamente requerimientos de usuario incompletos. Esto significa que los estimadores 
tienen muy poca informacion con la que trabajar. El analisis y la especificacion de requeri- 
mientos son costosos, y los gestores de la compafiia necesitan una estimacion inicial del cos- 
te del proyecto antes de que puedan tener un presupuesto aprobado para desarrollar requeri- 
mientos mas detallados o un prototipo del sistema. 

En estas circunstancias, «pricing to win» es una estrategia utilizada comunmente. La no- 
cion de «asignar precios para ganar» parece ser inmoral y poco apropiada para los negocios. 
Sin embargo, tiene algunas ventajas. El coste del proyecto se acuerda en base a un borrador 
de la propuesta. Entonces se llevan a cabo negociaciones con el cliente para determinar una 

^k^toi ^p^™j'^)^3^"«^^^fa»'jm«fa ^h; ta cs P cc '^' cac '° n v ' cne delimitadapor el coste acor- 
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ble a sus estaciones de servicio. No hay un documento detallado de requerimientos para este 
sistema, por lo que los desarrolladores estiman que un precio de 900.000 $ sera suficiente- 
mente competitivo y encajara en el presupuesto de la compania de carburantes. Despues de 
conseguir el contrato, ellos negociaran los requerimientos detallados del sistema y que fun- 
cionalidades basicas seran entregadas; entonces estimaran costes adicionales de otros reque- 
rimientos. La compania de carburantes no perdera necesariamente aqui, porque ha concedi- 
do el contrato a una compania en la que puede confiar. Los requerimientos adicionales pueden 
ser parte de un future presupuesto, por lo que los presupuestos iniciales de la compania de car- 
burantes no seran perturbados con altos costes iniciales de software. 

26.3 Modelado algontmico de costes 

El modelado algontmico de costes utiliza una formula matematica para predecir los costes del 
proyecto basandose en estimaciones del tamano del proyecto, el numero de ingenieros soft- 
ware, y otros factores de proceso y producto. Un modelo algoritmico de costes puede cons- 
truirse analizando los costes y los atributos de proyectos completados y encontrando una for- 
mula que los englobe y aproxime hacia la experiencia actual. 

Los modelos algoritmicos de costes se utilizan principalmente para hacer estimaciones de 
coste de desarrollos software, pero Boehm (Boehm etal., 2000) describe una serie de otros usos 
para la estimacion algoritmica de costes, que incluyen estimaciones para investigadores en 
companias software, estimaciones de estrategias alternativas para ayudar a evaluar los riesgos, 
y estimaciones para la tomade decisiones sobre reutilizacion, reorganizaciono subcontracion. 

En su formula mas general, una estimacion algoritmica de costes puede ser expresada 
como: 

Esfuerzo = A x Tamano - x M 

A es un factor constante que depende de las practicas organizacionales locales y del tipo 
de software que se desarrolla. El Tamano es una valoracion del tamano del codigo del soft- 
ware o una estimacion de la funcionalidad expresada en puntos de funcion o puntos objeto. 
El valor del exponente B por lo general se encuentra entre 1 y 1,5. M es un multiplicador ge- 
nerado al combinar diferentes procesos, atributos del producto y del desarrollo, como la de- 
pendencia de requerimientos del software y la experiencia del equipo de desarrollo. 

La mayoria de los modelos algoritmicos de estimacion tienen un componente exponencial 
(B en la ecuacion anterior) asociados con la estimacion del tamano. Esto refleja el hecho de que 
el coste no se incremente linealmente con el tamano del proyecto. Si el tamano del software se 
incrementa, incurrimos en costes extras debidos a la sobrecargade la comunicacion en grandes 
equipos, gestion de configuraciones mas complejas, mayores dificultades en la integracion, en- 
tre otras. Por lo tanto, cuanto mas grande sea el sistema, mayor sera el valor de este exponente. 

Desafortunadamente, todos los modelos algoritmicos padecen las mismas dificultades ba- 
sicas: 

1 . A menudo es dificil estimar cl T a m a n o cn una primera etapa de un proyecto donde so- 
lamente esta disponible la especificacion. Las estimaciones de los puntos de funcion 
y de los puntos objeto son mas faciles de realizar que las de tamano del codigo, pero 
frecuentemente pueden ser imprecisas. 

2. Las estimaciones de los factores B y M son subjetivas. Las estimaciones varian de una 
persona a otra, dependiendo de su conocimiento y experiencia. 
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El numero de Hneas de codigo fiiente en un sistema terminado es la metrica basica usada 
en muchos modelos algoritmicos de costes. La estimacion del tamano puede comprender la 
estimacion por analogia con otros proyectos, la estimacion de convertir los puntos de funcion 
o puntos objeto al tamano del codigo, la de los valores del tamano de los componentes del sis- 
tema, y lautilizacion de un componente de referencia conocido para estimarel tamano de los 
componentes, o simplemente puede seruna cuestion dejuicio de ingenieria. 

La estimacion precisa del tamano del codigo es dificil en etapas tempranas del proyecto 
por que el tamano del codigo depende de decisiones de diseno que todavia no se han tornado. 
Por ejemplo, una aplicacion que requiere una gestion de datos compleja puede usar una base 
de datos comercial o implementar su propio sistema gestor de datos. Si se utiliza la base de 
datos comercial, el tamano del codigo sera menor, pero puede sernecesario un esfuerzo adi- 
cional debido a limitaciones de rendimiento del producto comercial. 

El lenguaje de programacion utilizado en el desarrollo del sistema tambien afecta al nu- 
mero de Hneas de codigo a desarrollar. Un lenguaje como Java podria generar mas Hneas de 
codigo que si se utilizara lenguaje C. Sin embargo, este codigo extra permite mas comproba- 
ciones en tiempo de compilacion, por lo que los costes de validacion probablemente se redu- 
cen. (,C6mo se tiene esto en cuenta? Mas aun. tambien se tiene que estimar la magnitud de la 
reutilizacion en el proceso de desarrollo de software y ajustar la estimacion del tamano para 
tomar esta en cuenta. 

Si se utilizan los modelos algoritmicos para estimar los costes, se debe crearun rango de 
estimaciones (la peor, la esperada y la mejor) en lugar de una sola estimacion y aplicar la for- 
mula de costes a todas ellas. Las estimaciones son mas precisas cuando se conoce el tipo de 
software a desarrollar, cuando se ha calibrado el modelo utilizando datos locales, y cuando el 
lenguaje de programacion y el hardware han sido predefinidos. 

La precision de las estimaciones producidas porun modelo algoritmico de costes depende 
de la informacion del sistema que este disponible. Conforme avance el proceso software, mas 
informacion estara disponible y las estimaciones seran mas precisas cada vez. Si la estima- 
cion inicial del esfuerzo requerido es dex meses de esfuerzo, el rango puede estar compren- 
dido entre 0,25.v y 4.v en la primera propuesta. Este se afinara durante el proceso de desarro- 
llo, como muestra la Figura 26.5. Esta figura, adaptada de un articulo de Boehm (Boehm ex 
al, 1995), refleja la experiencia de un buen numero de proyectos software. Por supuesto, jus- 
to antes de que se entregue el sistema, se puede haceruna estimacion muy precisa. 



estimada. 



Figura 26.5 
Incertidumbre 




Entrega 
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26.3.1 □ modelo de COCO MO 

Se han propuesto varios modelos algoritmicos como base para estimar el esfuerzo, agenda y 
costes de un proyecto software. Estos son similares conceptualmente, pero utilizan diferentes 
valores en sus parametros. El modelo que se analiza aqui es el modelo COCOMO. El mode- 
lo COCOMO es un modelo empirico que se obtuvo recopilando datos de varios proyectos 
grandes. Estos datos fueron analizados para descubrir las formulas que mejor se ajustaban a 
las observaciones. Estas formulas vinculan el tamafio del sistema y del producto, factores del 
proyecto y del equipo con el esfuerzo necesario para desarrollar el sistema. 
Se ha elegido COCOMO por las siguientes razones: 

1. Esta bien documentado, es de dominio publico y lo apoyan el dominio publico y las 
herramientas comerciales. 

2. Se ha utilizado y evaluado ampliamente. 

3. Tiene una gran tradicion desde su primera version en 1981 (Boehm, 1981), pasando 
por un refinamiento para el desarrollo de software en AD A (Boehm y Royce, 1989), 
hasta su version mas reciente, C O C O M O II, publicada en 2000 (Boehm et ah, 2000). 

Los modelos COCOMO son comprensibles, con un gran mimero de parametros, los cua- 
les pueden tomar un rango de valores. Estos son complejos y no se puede dar una descripcion 
completa aqui . Bastauna simple exposicion de las caracteristicas esenciales para comprender 
los modelos algoritmicos de costes. 

La primera version del modelo COCOMO, COCOMO 81, fue un modelo de tres niveles 
donde estos reflejaban el detalle del analisis de la estimacion del coste. El primer nivel (basi- 
co) provee una estimacion inicial burda, el segundo nivel la modifica utilizando una serie de 
multiplicadores de proyecto y proceso, y el nivel mas detallado produce estimaciones para las 
diferentes fascs del proyecto. La Figura 26.6 mucstra la formula basica dc C O C O M O como 
los diferentes tipos de proyectos. El multiplicador M refleja caracteristicas del producto, pro- 
yecto y del personal. 

COCOM081 supone que el software se desarrolla segun un proceso en cascada (vease el Ca- 
pitulo 4) usando lenguajes de programacion imperatives estandares como C o FORTRAN. Sin 
embargo, ha habido cambios radicales en el desarrollo de software desde que se propuso esta ver- 
sion inicial. El prototipado y el desarrollo incremental son modelos de proceso utilizados co- 
munmente. El software se desarrolla ahora ensamblando componentes reutilizables y vinculan- 
dolos mediante un lenguaje de secuencia de comandos (scripts). Los sistemas que hacen un uso 
intensivo de datos se desarrollan con lenguajes como SQL y gestores de base de datos comer- 
ciales. Se crea nuevo software aplicando reingenieria sobre el software ya existente. Existen he- 
rramientas CASE para ayudar en muchas de las actividades del proceso del software. 





Simple 


PM 


= 2,4 (KDSI) ,fls x M 


Aplicadones bien entendidas y desanolladas por equipos pe- 
queftos. 


Moderado 


PM 


«= 3,0 (KDSt)' " x M 


Proyectos mas complejos donde los miembros del equipo 
pueden tener experiertcia Kmitada en este tipo de sistemas. 


Empotrado 


PM 


- 3,6 <KDS0 1JO x M 


Proyectos complejos donde et software es parte de un con- 
junto complejo de hardware, reglas y procedimientos. 



Figura 26.6 Modelo basico de COCOMO 81. 
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Teniendo en cuenta estos cambios, el modelo COCOMOII considera diferentes enfoques 
para el desarrollo de software, como el de la construccion de prototipos, el desarrollo basado 
en componentes y el uso de programacion con bases de datos. COCOMO II soporta el mo- 
delo de desarrollo en espiral (vease el Capitulo 4) y engloba varios niveles que producen es- 
timaciones detalladas de forma incremental. Estos pueden utilizarse en sucesivas iteraciones 
en el desarrollo en espiral. La Figura 26.7 muestra los niveles de COCOMO II y sus reco- 
mendaciones de uso. 

Los niveles de COCOMO II son los siguientes: 

1. Nivel de construccion de prototipos. Este presume que el sistema es creado mediante 
componentes reutilizables, scripts y programacion de base de datos. Fue diseiiado 
para hacer estimaciones de desarrollo de prototipos. Las estimaciones de tamaiio del 
software estan basadas en puntos de aplicacion, y se utiliza una formula simple (ta- 
maiio/productividad) para estimar el esfuerzo requerido. El concepto de puntos de 
aplicacion es el mismo que el de puntos objeto expuesto en la Seccion 26.1, pero el 
nombre fue cambiado para evitar confusiones con el desarrollo orientado a objetos. 

2. Nivel de diseho inicial. Este nivel se utiliza en etapas tempranas del diseno del siste- 
ma, despues de que los requerimientos hayan sido establecidos. Las estimaciones es- 
tan basadas en puntos de funcion, los cuales se convierten a numero de lineas de co- 
digo. La formula permite seguir el estandar expuesto anteriormente con un conjunto 
de siete multiplicadores. 

3. Nivel de reutilizacion. Este nivel se utiliza para calcular el esfuerzo requerido para in- 
tegrar componentes reutilizables y/o el codigo que es automaticamente generado por 
herramientas de diseflo o programas de traduccion. Normalmente es utilizado junto 
con el nivel de post-arquitectura. 

4. Nivel de postarquitectura. Una vez disefiado el sistema, se puede hacer una estimacion 
mas precisa del tamaiio del software. Otra vez se utiliza la formula estandar para la es- 
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Figura 26.7 Los niveles del COCOMO H. 
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timacion del coste expuesta anteriormente. Sin embargo, esta incluye un conjunto de 
17 multiplicadores que reflejan las habilidades de! personal y las caracteristicas del 
producto y del proyecto. 

Por supuesto, en sistemas grandes, diferentes partes pueden ser desarrolladas utilizando di- 
versas tecnologias, y puede que no sea preciso estimar todas las partes con el mismo nivel de 
precision. En estos casos, se puede utilizar el modelo apropiado para cada parte del sistema y 
combinar los resultados para crear una estimacion del sistema completo. 

Nivel de construccion de prototipos 

El nivel de construccion de prototipos fue introducido enCOCOMOII para dar soporte a 
la estimacion del esfuerzo requerido para el prototipado de proyectos y para proyectos en 
que el software se desarrolla utilizando componentes existentes. Se basa en una estimacion 
de los puntos de aplicacion con pesos (puntos objeto), la cual se divide entre una cifra es- 
tandar de la productividad estimada. Luego se ajusta la estimacion de acuerdo con la difi- 
cultad de desarrollo de cada punto objeto (Boehm ei al., 2000). La productividad del pro- 
gramador depende de la experiencia y de la capacidad del desarrollador, y de las 
caracteristicas de la herramientas CASE utilizadas para apoyar el desarrollo. La Figura 
26.8 muestra los valores de productividad sugeridos por los desarrolladores del modelo 
(Boehm et ah, 1995). 

En este nivel, la reutilizacion es comun, y algunos de los puntos de aplicacion se pueden 
implementarcon componentes reutilizables. Enconsecuencia, se deberaajustar la estimacion 
obtenida mediante el total de puntos de aplicacion, teniendo en cuenta el porcentaje de reuti- 
lizacion esperado. Por lo tanto, la formula para el calculo del esfuerzo para el prototipado del 
sistema es: 

PM = (NAP x (1 - %reutilizacion/100)) / PROD 

PM es el esfuerzo estimado en personas/mes. NAP es el total de puntos de aplicacion en el 
sistema a desarrollar. 0 o reutilizacion es una estimacion de la cantidad de codigo reutilizado 
en el desarrollo. PROD es la productividad medida en puntos objeto como muestra la Figu- 
ra 26.8. El modelo presupone que no hay esfuerzo adicional derivado de la reutilizacion. 

Nivel de diseno inicial 

Este nivel se utiliza cuando hemos acordado los requerimientos de usuario y se han iniciado 
las primeras etapas del proceso de diseno. Sin embargo, no necesitamos una arquitectura de- 
tallada del diseno para realizar estas estimaciones. La meta en este nivel es hacer una estima- 
cion aproximada sin demasiado esfuerzo. En consecuencia, se asumiran simplificaciones, 
como que el esfuerzo de integrar el codigo reutilizable es cero. Las estimaciones de diseno 
inicial son la opcion mas util para evaluar distintas alternativas a fin de implementar los re- 

Expenencta y capaddad 

de los detarroltodoMS Muy baja, Baja Media Aha Muyalta 
Figura 26.8 Madurez y capaddad 

Productividad de fas herramientas CASE Muybaja Baja Media Aha Muyafta 

medida en puntos PROD (NOP/mes) 4 7 13 25 50 

objeto. 
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querimientos del usuario. Las estimaciones en este nivel estan basadas en la formula estandar 
para modelos algoritmicos: 

Esfuerzo = A x Tarn a no- x M 

Basandose en su gran cantidad de datos historicos, Boehm propone que el coeficiente A sea 
de 2,94. El tamano del sistema es expresado en KSLOC, es decir, el niimero de miles de lineas 
de codigo fuente. Este se calcula estimando el numero de puntos de funcion en el software, y 
convirtiendo este a KSLOC utilizando tablas estandar, que relacionan el tamano del software 
con los puntos de funcion dependiendo del lenguaje de programacion. 

El exponente B refleja el esfuerzo creciente requerido al incrementarse el tamano del pro- 
yecto. Este no se fija para diferentes tipos de sistemas, como enelCOCOM081, pero pue- 
de variar desde 1,1 hasta 1,24 dependiendo de la novedad del proyecto, la flexibilidad de desa- 
rrollo, los procesos utilizados para la resolucion de riesgos, la cohesion del equipo de 
desarrollo y el nivel de madurez del proceso de la organizacion (vease el Capitulo 28). La for- 
ma de calcular este exponente se muestra en la descripcion del nivel de postarquitectura del 
COCOMO II. 

El multiplicador M en COCOMO II estabasado en un conjunto simplificado de siete ca- 
racteristicas de proyecto y de proceso que influyen en la estimacion. Este puede hacer que se 
incremente o decremente el esfuerzo requerido. Estas caracteristicas utilizadas en el nivel de 
disefio inicial son fiabilidad y complejidad del producto (RCPX), reutilizacion requerida 
(RUSE), la dificultad de la plataforma (PDIF), la capacidad del personal (PERS), la experien- 
cia del personal (PREX), agenda (SCED) y facilidades de apoyo (FCIL). Estas se pueden esti- 
mar directamente sobre una escala de seis puntos donde 1 corresponde a valores muy bajos 
de los multiplicadores y 6 corresponde a valores muy altos. 

Esto nos lleva a la siguiente formula de esfuerzo: 
PM - 2,94 x Tamano* x M 
donde: 

M = PERS x RCPX x RUSE x PDIF x PREX x FCIL x SCED 
Nivel de reutilizacion 

Como ya vimos en los Capitulos 18 y 19, ahora es muy comun reutilizar software, y los sis- 
temas grandes tienen un porcentaje significativo de codigo reutilizado de otros proyectos an- 
teriores. Este nivel de reutilizacion se emplea para estimar el esfuerzo requerido para integrar 
codigo reutilizable y codigo generado. 

COCOMO II considera 2 tipos de codigo reutilizado. El codigo de caja negra es el codigo 
que puede ser reutilizado sin entender el codigo ni teniendo que hacer cambios en el. El es- 
fuerzo de desarrollo para este tipo de codigo es 0. El codigo que ha de ser adaptado para in- 
tegrarlo con el codigo nuevo u otros componentes reutilizados recibe el nombre de codigo de 
caja blanca. Este supone un esfuerzo de desarrollo ya que tendremos que entenderlo y modi- 
ficarlo para que funcione correctamente en el sistema. 

Ademas, muchos sistemas incluyen codigo generado automaticamente desde el modelo del 
sistema a traves de traductores automaticos. El generador posee unas plantillas estandar, el 
modelo del sistema es analizado, y el codigo base es generado a partirde estas plantillas es- 
tandar y los datos del modelo. El nivel de reutilizacion de COCOMO II incluye una parte es- 
pecificapara estimar los costes asociados a este codigo generado automaticamente. 
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Para el codigo generado automaticamente, el modelo estimael numero de personas/mes 
necesarias para integrar este codigo. La formula para estimar el esfuerzo es: 

•-Auio = (ASLOC x AT/100) / ATPROD // Estimacion para el codigo generado 

ATes el porcentajede codigo adaptado que se genera automaticamente y ATPROD es lapro- 
ductividad de los ingenieros que integran dicho codigo. Boehm eiai, 2000) han medido AT- 
PROD en torno a 2.400 lineas por mes. Por lo tanto, si hay un total de 20.000 lineas de codi- 
go reutilizado del tipo cajablanca enun sistemay un 30% de este se genera automaticamente, 
entonces el esfuerzo requerido para integrar este codigo sera: 

(20.000 x 30/100) / 2400 = 2,5 personas/mes// Ejemplo de codigo generado 

Cuando un sistema incluye algo de codigo nuevo y algunos componentes reutilizables de 
caja blanca que deben ser integrados, se usa otro componente del nivel de reutilizacion. En 
este caso el nivel de reutilizacion no calcula el esfuerzo directamente. A pesar de estar basa- 
do en el numero de lineas de codigo reutilizadas, este calcula una cifra equivalente en lineas 
de codigo nuevo. 

Por lo tanto, si 30.000 lineas de codigo han de ser reutilizadas, el tamafio nuevo equiva- 
lente estimado puede ser 6.000. Esencialmente, reutilizar 30.000 lineas de codigo equivale a 
escribir 6.000 lineas de codigo nuevo. La cifra calculada se suma al numero de lineas de co- 
digo nuevo a desarrollardel nivel depostarquitecturade CO CO MO II. 

Las estimaciones en el nivel de reutilizacion son: 

ASLOC - Numero de lineas de codigo en los componentes que deben ser adaptados 
E5L0C - numero equivalente en lineas de codigo nuevo 

La formula utilizada para calcular ESLOC tiene en cuenta el esfuerzo necesario para com- 
prender el software, para hacer cambios en el codigo a reutilizar y los cambios en el sistema 
para integrar este codigo. Tambien tiene en cuenta la cantidad de codigo que se genera auto- 
maticamente, donde el esfuerzo de desarrollo se calcula como veremos mas adelante en esta 
seccion. 

La siguiente formula se utiliza para calcular el numero equivalente de lineas de codigo: 
ESLOC = ASLOC x (1 - AT/100) x AAM 

ASLOC se reduce de acuerdo con un porcentaje de codigo automaticamente generado. 
AAM es el multiplicador de ajuste de la adaptacion, el cual tiene en cuenta el esfuerzo reque- 
rido en la reutilizacion de codigo. Basicamente,AAM es la suma detres componentes: 

1. Un componente de adaptacion (llamadoAAF) que representael costede hacer los cam- 
bios en el codigo reutilizado. Este tiene en cuenta cambios de diseno, codigo e inte- 
gracion. 

2. Un componente de comprension (llamado SU ) que representa el coste de entender el 
codigo que se va a reutilizar y la familiarizacion del ingeniero con el codigo. Los va- 
lores de SU van desde 50 para codigo complejo no estructurado hasta 10 para codigo 
orientado a objetos bien escrito. 

3. Un factor de calculo (llamado AA ) que representa el coste de la tomade decisiones para 
la reutilizacion. Esto es, siempre es necesario algun analisis para decidir que codigo 
puede ser reutilizado. AA varia entre 0 y 8 segun la cantidad de esfuerzo necesaria. 

El nivel de reutilizacion no es un modelo lineal. Necesitaremos esfuerzo si la reutilizacion 
se considera como hacer una valoracion de si es posible la reutilizacion. Porlo tanto, cuanta 
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mas reutilizacion se contemple, los costes de reutilizacion por unidad de codigo reutilizado 
seran mayores. 

Nivel de postarquitectura 

El nivel de postarquitectura es el nivel mas detallado de todos los del COCOMO II. Se utili- 
za una vez que conocemos el diseno arquitectonico del sistema, es decir, cuando conocemos 
la estructura de subsistemas. 

Las estimaciones producidas en el nivel de postarquitectura estan basadas en la misma for- 
mula basica (PM = A x Tamano" x M) utilizada en las estimaciones de diseno inicial. Sin 
embargo, la estimacion del tamano del software debera ser mas precisa en esta etapa del pro- 
ceso de desarrollo, y se utiliza un conjunto mas extenso de atributos (1 7 en lugar de 7) de pro- 
ducto, proceso y organizacion para refinar el calculo del esfuerzo inicial. Es posible utilizar 
mas atributos, ya que tenemos mas informacion en esta etapa acerca del proceso de desarro- 
llo y del producto. 

La estimacion del numero de lineas de codigo se calcula utilizando tres componentes: 

1. Una estimacion del numero total de lineas nuevas de codigo a desarrollar. 

2. Una estimacion del numero de lineas de codigo fuente equivalentes (ESLOC) calcula- 
das usando el nivel de reutilizacion. 

3. Una estimacion del numero de lineas de codigo que tienen que modificarse debido a 
cambios en los requerimientos. 

Estas tres estimaciones se anaden para obtener el tamano total del codigo (KSLOC) que uti- 
lizaremos en la formula para el calculo del esfuerzo. El componente final en la estimacion — 
el numero de lineas de codigo modificado — refleja el hecho de que los requerimientos del 
software siempre cambian. Los programas tienen que reflejar estos cambios en los requeri- 
mientos y, por lo tanto, se ha de desarrollar un nuevo codigo. Por supuesto, la estimacion del 
numero de lineas que cambiaran no es facil, y habra mas incertidumbre que en las estimacio- 
nes de desarrollo. 

El termino exponencial (B) en la formula para el calculo del esfuerzo tiene tres posibles 
valores en CO CO MO I. Estos se relacionaban con los diferentes niveles de complejidad del 
proyecto. Puesto que los proyectos son cada vez mas complejos, los efectos de incrementar 
el tamano del sistema son cada vez mas importantes. Sin embargo, las buenas practicas y los 
procedimientos organizacionales pueden controlaresta«escala de deseconomia». Esto se re- 
coge en C O C O M O II, donde el rango de valores para el exponente B es continuo en lugar de 
discrete El exponente se estima considerando 5 factores de escala, como se muestra en la Fi- 
gura 26.9. Estos factores pueden tomarse de 6 valores que van desde muy bajo hasta extra alto 
(5 a 0). Los valores resultantes se suman, se dividen entre 100 y al resultado se le suma 1.01 
para obtener el exponente que se debe utilizar. 

Para ilustrar esto, imaginemos que una organizacion trabaja en un proyecto en el que se 
tiene poca experiencia de dominio. El cliente del proyecto no ha definido el proceso a utili- 
zar y no proporciona suficiente tiempo en el calendario del proyecto para hacerun analisis de 
riesgos. Se tiene que formarun nuevo equipo de desarrollo para implementar este sistema. La 
organizacion recientemente ha puesto en proceso un programa de perfeccionamiento y ha ob- 
tenido el Nivel 2 del modelo C M M (vease el Capitulo 28). Los posibles valores de los facto- 
res de escala utilizados en el calculo del exponente son: 

• Precedentes: Este es un proyecto nuevo para la organizacion — valor Bajo (4) 

• Flexibilidad de desarrollo: No se involucra al cliente — valor Muy alto (1) 
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Figura 26.9 Factores de escala utilizados en el calculo del exponente en COCOMO II. 



• Resolution de la arquitecturalriesgo: No se lleva a cabo un analisis de riesgos — valor 
Muy bajo (5) 

• Cohesion del equipo: Creadon de un equipo, por lo que no tenemos informacion — va- 
lor Nominal (3) 

• Madurez del proceso: Algun control del proceso en su lugar — valor Nominal (3) 

La suma de estos valores es 16, por lo que el exponente debe tomar un valor de 1,17 
(0,16 + 1,01). 

Los atributos (Figura 26.10) que se utilizan para ajustar las estimaciones iniciales y crear 
el multiplicador M en el nivel de postarquitectura se puede dividir en cuatro clases: 

1 . Los atributos de producto se refieren a las caracteristicas requeridas del producto soft- 
ware a desarrollar. 

2. Los atributos de la computadora son restricciones impuestas sobre el software o lapla- 
taforma hardware. 

3. Los atributos del personal son multiplicadores que tienen en cuenta la experiencia y 
las capacidades de las personas que trabajan en el proyecto. 

4. Los atributos del proyecto se refieren a las caracteristicas particulars del proyecto de 
desarrollo software. 

La Figura 26.1 1 muestra un ejemplo de como influyen estos conductores de costes en 
las estimaciones del esfuerzo. Se tomo un valor de 1,17 para el exponente y se supuso que 
RELY, CPLX, STOR, TOOL y SCED son los conductores de costes clave en el proyecto. Los 
otros conductores de costes tienen un valor nominal de 1, por lo que no afectan al calculo 
del esfuerzo. 

En la citada figura, a los conductores clave de los costes se les asigna valores maximos y 
minimos para mostrar como influyen en la estimacion del esfuerzo. Los valores que se toman 
son los provenientes del manual de referencia de COCOMO II (Boehm, 1997) Puede verse 
que los valores altos para los conductores de costes conducen a una estimacion del esfuerzo 
que es tres veces la estimacion inicial, mientras que los valores bajos reducen la estimacion 
alrededor de 1/3 de la original. Esto resalta la gran diferencia entre los diferentes tipos de pro- 
yectos y las dificultades de transferir la experiencia de un dominio de la aplicacion a otro. 
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Figura 26.10 
Conductores del 
coste del proyecto. 
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Proyecto 
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SITE 


Proyecto 


Ambito de los distintos lugares de trabajo y sus comuntcactones 



Esla formula propuesta por los desarrolladores de COCOMO 11 refleja su experiencia y 
datos, pero parece ser muy compleja para su utilizacion practica. Existen muchos atributos 
y demasiadas incertidumbres al estimar sus valores. En principio, cada usuario calibra el 
modelo y los atributos de acuerdo con sus propios dalos historicos de proyecto, y estos re- 
flejaran las circunstancias particulares dentro del modelo. Sin embargo, en la practica, po- 
cas organizaciones han recogido suficientes datos de proyectos anteriores de forma que per- 
mitan una calibracion del modelo. La utilizacion practica de COCOMO II empieza 
normalmente con los valores publicados de los parametros del modelo, y al usuario le es 



Figura 26.11 
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imposible saber la similitud de estos con su situacion real. Esto significa que el uso practi- 
ce) del modelo de CO CO MO es limitado. Las grandes organizaciones deben tener los re- 
cursos para contratar a un experto en estimacion de costes y utilizar los modelos de CO- 
COMO II. Sin embargo, para la mayor parte de las companias, el coste de calibrar y 
aprender a usar un modelo algoritmico como el de C O C O M O es alto, de forma que no es- 
taran dispuestos a introduciresta aproximacion. 

26.3.2 Modelos algontmlcos de costes en la planlflcaclon 

Una de las mas valiosas formas de utilizar el modelado algoritmico de costes es comparar 
las diferentes formas de invertir el dinero para reducir los costes del proyecto. Esto es parti- 
cularmente importante donde existen costes hardware/software y donde se necesita reclutar 
personal nuevo con habilidades especificas para el proyecto. El modelo algoritmico ayuda a 
evaluar los riesgos de cada opcion. El coste del modelo nos revela los gastos financieros aso- 
ciados a las diferentes decisiones de gestion. 

Consideremos un sistema empotrado para controlar un experimento que se lanzara al espa- 
cio. Los experimentos espaciales tienen que ser muy fiables y estan sujetos a limites de peso 
muy rigurosos. El numero de chips en una tarjeta electronica tiene que minimizarse. En ter- 
minos del modelo CO CO MO los multiplicadores de las restricciones y la fiabilidad son ma- 
yores que 1 . 

Existen tres componentes que hay que tomar en cuenta en el coste de este proyecto: 

1. El coste del hardware que ejecuta el sistema. 

2. El coste de la plataforma (computadora mas hardware) para desarrollar el sistema. 

3. El coste del esfuerzo requerido para desarrollar el software. 

La Figura 26. 1 3 muestra algunas posibles opciones a considerar. Estas incluyen gastar mas en 
el hardware para reducir los costes del software o invertir en mejores herramientas de desarrollo. 

Los costes de hardware adicionales son aceptables en este caso debido a que el sistema es 
especializado y no se produce en masa. Sin embargo, si el hardware se incorpora en produc- 
tos de consumidor, invertir en el hardware para reducir los costes de hardware es raramente 
aceptable debido a que incrementa el coste unitario del producto. 

La Figura 26.13 muestra los costes del hardware, software y totales para las opciones 
A - F de la Figura 26. 12. Aplicar el modelo CO COMO II sin los conductores de costes pre- 
dice un esfuerzo de 45 personas/mes para desarrollar el software incrustado para esta apli- 
cacion. El coste promedio de una persona/mes de esfuerzo es de 15.000 $. 

Los multiplicadores relevantes se basan en las restricciones de almacenamiento y tiempo 
de ejecucion (TIMEy STOR), la disponibilidad de herramientas de soporte (compiladores, et- 
cetera) para el desarrollo del sistema (TOOL) y la experiencia del equipo de desarrollo en la 
plataforma (LTEX). En todas las opciones, el multiplicador de fiabilidad (RELY) es 1,39, que 
indica que se precisa un esfuerzo adicional significativo para desarrollar un sistema fiable. 

El coste del software (SC) se calcula como sigue: 

SC - Esfuerzo estimado x RELY x TIME x STOR x TOOL x EXP x 15.000 S 

La opcion A representa el coste de construcciondel sistema con la ayuda y el personal exis- 
tentes. Representa un punto de comparacion. Las demas opciones consideran o mas gasto en 
el hardware o el reclutamiento de nuevo personal (con los costes y riesgos asociados). La op- 
cion B muestra que la actualizacion del hardware no reduce los costes necesariamente. La fal- 
ta de experiencia del personal incrementa los multiplicadores de experiencia invalidando la 
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A. Utilizar el hardware 
existente, sistema de desarrollo 
y equipo de desarrollo 



B. Actualizaci6n del procesador 
y de la memoria 



Los costos de hardware se incrementan 
La experiencia decrece 



C. S6I0 actualization 
de la memoria 



Los costos de hardware 
se incrementan 



D. Personal mis 
experimentado 



Figura 26.12 
Decisiones 
de gestion. 



E. Nuevo sistema 
de desarrollo 



Los costos de hardware se incrementan 
La experiencia decrece 



F. Personal con 
experiencia en hardware 



reduccion de losmultiplicadoresSTORyTIME. Actualmente es mas rentable actualizar la me- 
moria en lugar de actualizar toda la configuracion de la computadora. 

La opcion D parece ofrecer los costes mas bajos de todas las estimaciones basicas. No re- 
quiere un desembolso adicional de hardware, pero se debe reclutar nuevo personal para el pro- 
yecto. Si el personal estadisponible en lacompania, esta es probablemente la mejor opcion. 
Si no es asi, se debe reclutar personal del exterior y esto implica costes y riesgos importantes. 
Esto significa que las ventajas de coste de esta opcion son mucho menos significativas que las 
sugeridas en la Figura 26.13. La opcion C ofrece un ahorro de casi 50.000 $ que no implica 
practicamente riesgo alguno. Los administradores de proyectos conservadores probablemen- 
te seleccionaran esta opcion en lugar de la arriesgada opcion D. 

Las comparativas muestran la importancia de la experiencia del personal como un multi- 
plicador. Si se recluta personal de buena calidad con la experiencia adecuada, se pueden re- 
ducir los costes del proyecto de forma significativa. Esto es coherente con el analisis de los 
factores de productividad de la Seccion 26.1. Tambien revela que las inversiones en nuevo 
hardware y herramientas pueden no ser costeables. Tales estrategias son a menudo promovi- 
das por los desarrolladores a quienes les gusta aprender y trabajar con los nuevos sistemas. 
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Figura 26.13 Costes de las opciones de gestion. 



582 CAPITUL0 26 • Estlmaclon de costes del software 



Sin embargo, la perdida de experiencia es un efecto mas importante en los costes del sistema 
que los ahorros que provee el uso del nuevo sistema hardware. 

26.4 Duracion y personal del proyecto 

Asi como es necesario estimar el esfuerzo requerido para desarrollar un sistema de software y 
los costes totales del esfuerzo, los gestores de proyectos tambien estiman cuanto durara el des- 
arrollo del software y cuanto personal se necesita en el proyecto. El tiempo de desarrollo del pro- 
yecto se denomina duracion del proyecto. Cada vez mas, las organizaciones demandan dura- 
ciones mas cortas para que sus productos salgan al mercado antes que los de sus competidores. 

La relacion entre el numero de personas que trabajan en un proyecto, el esfuerzo total re- 
querido y el tiempo de desarrollo no es lineal. En cuanto crezca el numero de personas, se ne- 
cesitara mas esfuerzo. Las personas deben invertir mas tiempo en comunicarse y se requiere 
mas tiempo para definir las interfaces entre las partes del sistema. Doblar el numero de per- 
sonas (por ejemplo) no significa que la duracion del proyecto se reducira a la mitad. 

El modelo C O C O M O incluye una formula para estimar el tiempo de calendario (TDEV) re- 
querido para completarun proyecto. Esta formula es igual paratodos los niveles deCOCOMO: 

TDEV = 3 X (pM)<"-""-' , <-'«» 

PM es el calculo del esfuerzo y B es el exponente calculado (B es 1 para el nivel inicial de 
construccion de prototipos). Este calculo predice la duracion nominal del proyecto. 

Sin embargo, la duracion prevista del proyecto y la requerida por el plan del proyecto no 
son necesariamente la misma. La duracion planificada es mas corta o mas larga que la dura- 
cion media prevista. Sin embargo, existe un limite obvio para los cambios en la duracion, y 
el modelo C O C O M O II predice esto como : 

TDEV = 3 x (PM) (■■"•I SCEDPercentage/100 

SCDEPercentage es el porcentaje de incremento o decremento en la duracion nominal. Si 
la cifra prevista difiere significativamente de la duracion planificada, esto indicaque existe un 
alto riesgo de que surjan problemas para entregar el software como se planeo. 

Para ilustrar el calculo de la duracion del desarrollo en COCOMO, supongamos que un 
proyecto de software requiere 60 meses de esfuerzo de desarrollo (opcion C en la Figura 
26.12). Supongamos que el valor del exponente B es 1,17. A partirde laecuacion de la dura- 
cion, el tiempo requerido para completar el proyecto es: 

TDEV = 3 x (60)°'" = 13 meses 

En este caso, no existe compresion o expansion de la duracion, por lo que el ultimo termi- 
no de la formula no tiene efecto en los calculos. 

Una implicacion interesante del modelo C O C O M O es que el tiempo requerido para com- 
pletar el proyecto esta en funcion del esfuerzo total requerido para el proyecto. No depende 
del numero de ingenieros de software que trabajen en el proyecto. Esto confirma la nocion de 
que agregar mas personas al proyecto probablemente no ayudara a reducir la duracion. Myers 
(Myers, 1989) analiza los problemas de aceleracion de la duracion. Senala que en los pro- 
yectos de software aparecen problemas importantes si se trata de desarrollarlos sin permitir 
suficiente tiempo de calendario. 

Dividir el esfuerzo requerido en un proyecto por la duracion del proyecto no da una indi- 
cacion util del numero de personas requeridas para el equipo del proyecto. Generalmente, un 
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pequeno niimero de personas es necesario para entregar el diseno inicial del proyecto. El equi- 
po crece durante la implementacion y las pruebas del sistema, y finalmente vuelve a decrecer. 
Un crecimiento muy rapido del personal del proyecto a menudo esta correlacionado con re- 
trasos en la duracion del proyecto. Por lo tanto, los administradores del proyecto deben evi- 
tar agregar mucho personal a un proyecto en las etapas iniciales de su ciclo de vida. 

El esfuerzo se puede modelar por la llamada curva de Rayleigh (Londeix, 1987) y el mo- 
delo de estimacion de Putnam (Putnam, 1978), el cual incorpora un modelo para el personal 
del proyecto que se basa en estas curvas. El modelo de Putnam tambien incluye el tiempo de 
desarrollo como factor clave. Si se reduce el tiempo de desarrollo, el esfuerzo requerido para 
desarrollar el sistema crece exponencialmente. 
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«Ten unmyths of project estimation». Un articulo pragmatico en el que se habla acerca de las dificultades practicas 
de la estimacion de costes ycambia algunos supuestos fundamentales en esta area. [P. Armour, Comm. ACM, 45(H), 
noviembre de 2002.] 
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C APITU LO 26 



Estimacion de costes del software 



Software Cost Estimation with COCOMOII. Este es el libro defmitivo sobre el modelo COCOMO 11. En el se hace una 
descripcion exhaustiva del modelo con ejemplos e incorpora software que implementa el modelo. Es muy detalla- 
do y facil de leer. (B. Boehm ef ai, 2000, Prentice Hall.) 

Software Project Management: Readings and Cases. Una seleccion de articulos y casos de estudio sobre la gestion 
de proyectos de software que es particularmente buena en el tratamiento del modelado algoritmico de costes. [C. 
F. Kemerer (ed.), 1997, Irwin.] 

«Cost models for future software life cycle processes: COCOMO II». Una introduccion del modelo de estimacion de 
costes COCOMO II que incluye el razonamiento fundamental de las formulas utilizadas. (B. Boehm et ai., Annals of 
Software Engineering, % Balzer Science Publishers, 1995.) 



26.1 En que circunstancias puede una compania fijar un precio mucho mas alto, para un sistema software, que 
el sugerido por la estimacion de costes mas un considerable margen de beneficio. 

262 Describa dos metricas utilizadas para medir la productividad de los programadores. Comente brevemen- 
te las ventajas e inconvenientes de estas metricas. 

26.3 Para el desarrollo de sistemas empotrados en tiempo real grandes, sugiera cinco factores que probable- 
mente tengan un efecto significativo en la productividad del equipo de desarrollo de software. 

264 Las estimaciones de los costes son inherentemente arriesgadas, con independencia de la tecnica de esti- 
macion utilizada. Sugiera cuatro formas que permitan reducir los riesgos en una estimacion del coste. 

26.5 (,P° r 1 ue deben utilizarse varias tecnicas de estimacion en sistemas grandes y complejos? 

26.6 Un administrador de software esta a cargo del desarrollo de un sistema de software de seguridad critico 
que se disefia para controlar una maquina de radioterapia para tratar a los pacientes que sufren de can- 
cer. Este sistema esta incrustado en la maquina y debe ejecutarse en un procesadorde proposito especial 
con una cantidad fija de memoria (8 MB). La maquina se comunica con un sistema de base de datos de pa- 
cientes para obtener los detalles del paciente y, despues del tratamiento, automaticamente registra la do- 
sis de radiacion suministrada y otros detalles del tratamiento en la base de datos. 

El metodo COCOMO se utilizapara estimarel esfuerzo requerido para desarrollar este sistema y se cal- 
cula un estimado de 26 personas/mes. Todos los multiplicadores conductores de costes se ajustan a 1 
cuando se hace esta estimacion. 

Explique por que esta estimacion debe ajustarse para tener en cuenta al proyecto, al personal, al pro- 
ducto y a los factores organizacionales. Sugiera cuatro factores que podrian tener efectos importantes en 
la estimacion inicial de COCOMO y proponga valores posibles de estos factores. Justifique por que se ha 
incluido cada factor. 

26.7 De tres razones por las cuales las estimaciones algoritmicas de costes realizadas por diferentes organiza- 
ciones no son directamente comparables. 

26.8 Explique como utilizan los administradores el enfoque algoritmico para la estimacion de costes para el ana- 
lisis de opciones. Sugiera una situacion en la que los administradores elijan un enfoque que no se base en 
el coste mas bajo del proyecto. 
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26.9 Algunos proyectos de software muy grandes implican escribir millones de lineas de codigo. Indique en que 
medida pueden ser utiles los modelos de estimacion de costes para tales sistemas. ^Porque las suposi- 
ciones en las que se basan podrian no servalidas para sistemas de software muy grandes? 

26.10 <^Es etico que una empresa de un precio bajo para un contrato de software sabiendo los requerimientos son 
ambiguos y que fijaran un alto precio para los cambios subsecuentes requeridos por el cliente? 

26.11 ^Los administradores deberian utilizar la productividad medida durante el proceso de evaluacion del per- 
sonal? ^Que salvaguardas son necesarias para asegurar que la calidad no se vea afectada por esto? 



27 



Gestion 
de la calidad 



Objetivos 

El objetivo de este capitulo es introducirnos en la gestion de la 
calidad y la medicion del software. Cuando termine de leer este 
capitulo: 

• entendera el proceso de gestion de la calidad y las actividades 
del proceso de garantia, planificacion y control de la calidad; 

• entendera la importancia de los estandares en el proceso de 
gestion de la calidad; 

• entendera que son las metricas de la calidad y las diferencias 
entre metricas de prediction y metricas de control; 

• entendera como las mediciones pueden ser utiles en el calculo 
de los atributos de calidad del software; 

• sera consciente de las actuales limitaciones de la medicion del 
software. 



Contenido 

27. 1 Calidad de proceso y producto 

27.2 Garantia de la calidad y estandares 

27.3 Planificacion de La calidad 

27.4 Control de la calidad 

27.5 Medicion y metricas del software 
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La calidad del software se ha mejorado significativamente en los quince ultimos afios. Una 
de las razones ha sido que las compaiiias han adoptado nuevas tecnicas y tecnologias como 
el uso de desarrollo orientado a objetos y el soporte asociado de herramientas CASE. No 
obstante, tambien ha habido una mayor conciencia de la importancia de la gestion de la ca- 
lidad y de la adopcion de tecnicas de gestion de la calidad para desarrollo en la industria 
del software. 

Sin embargo, la calidad del software es un concepto complejo que no es directamente com- 
parable con la calidad de la manufacture de productos. En la manufacturacion, la nocion de 
calidad viene dadapor la similitud entre el producto desarrollado y su especificacion (Crosby, 
1979). En un mundo ideal, esta definicion deberia aplicarse a todos los productos, pero, para 
sistemas de software, existen estos problemas: 

1 . La especificacion se orienta hacia las caracteristicas del producto que el consumidor 
quiere. Sin embargo, la organizacion desarrolladora tambien tiene requerimientos 
(como los de mantenimiento) que no se incluyen en la especificacion. 

2. No se sabe como especificar ciertas caracteristicas de calidad (por ejemplo, manteni- 
miento) de una forma no ambigua. 

3. Como se indico en la Parte 1, en la que se estudio la ingenieria de requerimientos, es 
muy dificil redactar especificaciones concretas de software. Por lo tanto, aunque un 
producto se ajuste a su especificacion, los usuarios no lo consideran un producto de 
alta calidad debido a que no responde a sus expectativas. 

Se deben reconocer estos problemas con la especificacion del software y se tienen que di- 
senar procedimientos de calidad que no se basen en una especificacion perfecta. En concre- 
te), atributos del software como manten i bilidad, seguridad o eficiencia no pueden ser especi- 
ficados explicitamente. Sin embargo, tienen un efecto importante en como es percibida la 
calidad del sistema. Estos atributos se analizaran en la Seccion 27.3. 

Algunas personas piensan que la calidad puede lograrse definiendo estandares y procedi- 
mientos organizacionales de calidad que comprueban si estos estandares son seguidos por el 
equipo de desarrollo. Su argumento es que los estandares deben encapsular las buenas prac- 
ticas, lascualesnos llevan inevitablemente a productos de alta calidad. En lapractica, sin em- 
bargo, es mas importante la gestion de la calidad que los estandares y la burocracia asociada 
para asegurar el seguimiento de estos estandares. 

Los buenos gestores aspiran a desarrollar una «cultura de la calidad» donde todos sea- 
mos responsables de que el desarrollo del producto sea llevado a cabo obteniendo un alto 
nivel de calidad en este. Ellos fomentan equipos para responsabilizarse en la calidad de su 
trabajo y desarrollar nuevas formas para mejorar la calidad. Mientras estandares y procedi- 
mientos son las bases de la gestion de la calidad, los gestores de calidad experimentados re- 
conocen que hay aspectos intangibles en la calidad del software (elegancia, legibilidad, etc.) 
que no puede ser incorporada en los estandares. Ellos ayudan a la gente interesada en estos 
aspectos intangibles de calidad y fomentan comportamientos profesionales en todos los 
miembros del equipo. 

La gestion formal de la calidad es particularmente importante para equipos que desarro- 
llan sistemas grandes y complejos. La documentacion de la calidad es un registro de que es 
hecho por cada subgrupo en el proyecto. Esto ayuda a la gente a ver que tareas importantes 
no deben ser olvidadas o que una parte del equipo no haga suposiciones incorrectas acerca de 
lo que otros miembros han hecho. La documentacion de calidad es tambien un medio de co- 
municacion sobre el ciclo de vida de un sistema. Estapermite al grupo responsabilizarse de 
la evolucion del sistema para saber que ha hecho el equipo de desarrollo. 
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Para sistemas pequenos, la gestion de calidad es importante todavia, pero se debe adoptar 
una aproximacion mas informal. No son tan necesarios los documentos porque el grupo pue- 
de comunicarse informalmente. La clave de la calidad en el desarrollo de sistemas pequenos 
es el establecimiento de cultura de calidad y asegurarse de que todos los miembros del equi- 
po hacen una aproximacion positiva a la calidad del software. 

La gestion de calidad del software se estructura en tres actividades principales: 

1. Garantia de la calidad. El establecimiento de un marco de trabajo de procedimientos 
y estandares organizacionales que conduce a software de alta calidad. 

2. Planificacion de la calidad. La seleccion de procedimientos y estandares adecuados a 
partir de este marco de trabajo y la adaptacion de estos para un proyecto software es- 
pecifico. 

3. Control de la calidad. La definicion y fomento de los procesos que garanticen que los 
procedimientos y estandares para la calidad del proyecto son seguidos por el equipo 
de desarrollo de software. 

La gestion de la calidad provee una comprobacion independiente de los procesos de desa- 
rrollo software. Los procesos de gestion de la calidad comprueban las entregas del proyecto 
para asegurarse que concuerdan con los estandares y metas organizacionales (Figura 27. 1). El 
equipo de garantia de calidad debe ser independiente del equipo de desarrollo para que pue- 
dan tener una vision objetiva del software. Ellos transmitiran los problemas y las dificultades 
al gestor principal de la organizacion. 

Un equipo independiente debe ser responsable de la gestion de la calidad y debe informar 
al gestor del proyecto. El equipo de calidad no esta asociado con ningun grupo de desarrollo, 
sino que tiene la responsabilidad de la gestion de la calidad en toda la organizacion. La razon 
de esto es que los gestores del proyecto deben mantener el presupuesto y la agenda. Si apare- 
cen problemas, estos pueden verse tentados de comprometer la calidad del producto para 
mantener su agenda. Un equipo independiente de calidad garantiza que los objetivos organi- 
zacionales y la calidad no sean comprometidos por consideraciones de presupuesto o agenda. 



27.1 Calidad de proceso y producto 



Una suposicion subyacente de la gestion de calidad es que la calidad del proceso de desarro- 
llo afecta directamente a la calidad de los productos derivados. Esta suposicion viene de los 
sistemas manufactureros donde la calidad del producto esta intimamente ligada al proceso de 
produccion. En un sistema automatizado de produccion, el proceso implica configurary ope- 
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rar la maquinaria asociada al proceso. Si la maquinaria es operada correctamente, la calidad 
del producto continua. Se mide la calidad del producto y se cambia el proceso hasta conse- 
guir el nivel de calidad deseado. La Figura 27.2 ilustra esta aproximacion basada en proceso 
para conseguir la calidad del producto. 

Hay un vinculo claro entre la calidad del proceso y del producto en produccion debido a 
que el proceso es relativamente facil de estandarizar y monitorizar. 

Cada sistema de produccion se calibra, y debe producir una y otra vez productos de alta 
calidad. Sin embargo, el software no se manufacture, sino que se disefla. El desarrollo de soft- 
ware es un proceso mas creativo que mecanico, donde la experiencia y habilidades indivi- 
duals son importantes. La calidad del producto, seacual fuere el producto utilizado, tambien 
se ve afectada por factores externos, como la novedad de una aplicacion o la presion comer- 
cial para sacarun producto rapidamente. 

En el desarrollo software, por lo tanto, la relacion entre la calidad del proceso y la calidad 
del producto es muy compleja. Es dificil de medir los atributos de la calidad del software, 
como mantenibilidad, incluso despues de utilizar el software durante un largo periodo. En 
consecuencia, es dificil explicar como influyen las caracteristicas del proceso en estos atri- 
butos. Ademas debido al papel del diseno y la creatividad en el proceso software, no podre- 
mos predecir la influencia de los cambios en el proceso en la calidad del producto. 

A pesar de ello, la experiencia nos muestra que la calidad del proceso tiene una influencia 
significativa en la calidad del software. La gestion y mejora de la calidad del proceso debe mi - 
nimizar los defectos en el software entregado. 

La gestion de la calidad del proceso implica: 

1 . Definir estandares de proceso, como las revisiones a realizar, cuando llevarlas a cabo, 
etcetera. 

2. Supervisar el proceso de desarrollo para asegurar que se sigan los estandares. 

3. Hacer informes del proceso para el gestor del proyecto y para el comprador del soft- 
ware. 

Un problema de la garantia de la calidad basada en el proceso es que el equipo de garan- 
tia de la calidad (QA) insista en unos estandares de proceso independientemente del tipo de 
software a desarrollar. Por ejemplo, los estandares de calidad del proceso para sistemas criti- 
cos deben requerir una especificacion completa y aprobada antes de que comience la imple- 
mentacion. Sin embargo, algunos sistemas criticos pueden necesitar prototipado, lo cual im- 
plica empezar a implementar sin una especificacion completa. Existen situaciones en las que 
el equipo de gestion de calidad sugiere que este prototipo no se puede llevar a cabo debido a 
que su calidad no se puede supervisar. En tales situaciones, el gestor principal debe interve- 
nir para asegurar que el proceso de calidad ayude al desarrollo del producto en lugar de im- 
pedirlo. 



Figura 27.2 Calidad 
basada en procesos. 
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27.2 Garantia de la calidad y estandares 

La garantia de la calidad es el proceso que define como lograr la calidad del software y como 
la organizacion de desarrollo conoce el nivel de calidad requerido en el software. Como se in- 
dico anteriormente, el proceso QA se ocupa ante todo de definir o seleccionar los estandares 
que deben de ser aplicados al proceso de desarrollo software o al producto software. Como 
parte del proceso Q A, usted puede seleccionar herramientas y metodos que apoyen estos es- 
tandares. 

Podemos definir dos tipos de estandares como parte del proceso de garantia de calidad: 

1. Estandares de producto. Estos estandares se aplican sobre el producto software que se 
comienza a desarrollar. Incluyen estandares de documentacion, como cabecera de co- 
mentarios estandar para definicion de clases, y estandares de codificacion, que defi- 
nen como debe utilizarse el lenguaje de programacion. 

2. Estandares de proceso. Estos estandares definen los procesos que deben seguirse du- 
rante el desarrollo del software. Pueden incluirdefiniciones de procesos de especifi- 
cacion, diseno y validacion, asi como una descripcion de los documentos que deben 
escribirse en el curso de estos procesos. 

Como se propuso en la Seccion 27. 1, existe una relacion muy cercanaentre los estandares 
de producto y los estandares de proceso. Los estandares de producto se aplican a las salidas 
del proceso software y, en muchos casos, los estandares de proceso incluyen actividades de 
proceso especificas que garantizan que se sigan los estandares de producto. 

Los estandares de software son importantes por varias razones: 

1. Estan basadas en el conocimiento de la mejor o mas apropiada practica de la em- 
presa. A menudo, este conocimiento solo se adquiere despues de seguirun proceso 
de prueba y error. Tenerlo constituido en un estandar evita la repeticion de errores 
anteriores. Los estandares captan el conocimiento que es de valor para la organiza- 
cion. 

2. Proveen un marco de trabajo alrededor del cual se implementa el proceso de garantia 
de la calidad. Puesto que los estandares captan las mejores practicas, el control de la 
calidad sencillamente asegura que los estandares se siguen adecuadamente. 

3. Ayudan a la continuidad cuando una persona continua el trabajo que llevaba a cabo 
otra. Los estandares aseguran que todos los ingenieros de una organizacion adopten 
las mismas practicas. En consecuencia, se reduce el esfuerzo de aprendizaje cuando 
se comienza un nuevo trabajo. 

El desarrollo de los estandares de los proyectos de ingenieria del software es un proceso 
dificil y largo. Organizaciones nacionales e internacionales como el Departamento de Defen- 
sa de Estados Unidos, ANSI, BSI, OTAN y el IEEE han estado activas en la produccion de 
los estandares. Estos estandares generales se aplican a una variedad de proyectos. Organiza- 
ciones como la OTAN y otras organizaciones de defensa exigen que se sigan sus propios es- 
tandares en los contratos de software. 

Se han desarrollado estandares nacionales e internacionales para cubrir la terminologia, los 
lenguajes de programacion como Javay C++, las notaciones como los simbolos de los dia- 
gramas, los procedimientos para derivar y redactar los requerimientos de software, los pro- 
cedimientos de garantia de calidad, y los procesos de verificacion y validacion del software 
(IEEE, 2003). 
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Los equipos de garantia de calidad que desarrollan los estandares se apoyan en sus es- 
tandares organizacionales basados en estandares nacionales e internacionales. Utilizando 
estos estandares como punto de partida, el equipo de garantia de la calidad debe crear un 
«manual» de estandares. Este define los estandares que son apropiados para la organizacion. 
La Figura 27.3 muestra ejemplos de estandares que se pueden incluir en ese manual. 

Algunas veces, los ingenieros de software consideran a los estandares como burocraticos 
e irrelevantes para las actividades tecnicas de desarrollo de software. Esto es probable sobre 
todo cuando los estandares requieren llenar formularios tediosos y registrar el trabajo. Aun- 
que por lo general los ingenieros estan de acuerdo en que los estandares son necesarios, a me- 
nudo tienen buenas razones de por que dichos estandares no son necesariamente apropiados 
para su proyecto en particular. 

Para evitar estos problemas, los gestores de la calidad que fijan los estandares necesitan es- 
tar informados y tomaren consideracion los siguientes pasos: 

1. Involucrar a los ingenieros de software en el desarrollo de los estandares del proyec- 
to. Asi comprenderan la necesidad de disefiar los estandares y se comprometeran con 
ellos. El documento de los estandares no debe establecer simplemente que se sigan los 
estandares, sino que deben de incluirse razones de por que se tomaron decisiones par- 
ticulares. 

2. Revisary modificar los estandares de forma regular con el fin de reflejar los cambios 
en la tecnologia. Unavez que los estandares se desarrollan, tienden a plasmarse en un 
manual de estandares de la compania y a menudo existe cierta reticencia a cambiar- 
los. Un manual de estandares es esencial,perodebe evolucionarde acuerdo con las cir- 
cunstancias y la tecnologia existentes. 

3. Proveer herramientas de software para apoyar los estandares donde sea necesario, Los 
estandares burocraticos son la causa de muchas quejas debido al trabajo tedioso que 
se requiere para implementarlos. Si se dispone de una herramienta de apoyo, no se ne- 
cesitara mucho esfuerzo para seguir los estandares. 

Si se impone un proceso nopracticoal equipo de desarrollo, los estandares deproceso pue- 
den causar dificultades. Diferentes tipos de software requieren distintos procesos de desarro- 
llo. No existe razon para prescribir una forma particular de trabajo si esta es inapropiada para 
un proyecto o para un equipo. Cada gestor de proyecto tiene la facultad de modificar los es- 
tandares de proceso de acuerdo con circunstancias particulares. Sin embargo, los estandares 
relacionados con la calidad del producto y del proceso posterior a la entrega solo deben cam- 
biarse despues de cuidadosas consideraciones. 

El gestor del proyecto y el gestor de calidad pueden evitarse los problemas de estandares 
inapropiados si planean cuidadosamente la calidad. Deben decidir cuales son los estandares 



Figura 27.3 
Estandares 
de producto y 
de proceso. 





Formutario para revision del diseflo 


Conducts para la revision del dtseno 


Estructura del documento de requerimientos 


Sometimiento de documentor a CM 


Formato del encabezado del metodo 


Proceso de entrega de versiones 


Estilo de programacion en Java 


Proceso de a probation del plan del proyecto 


Formato del plan del proyecto 


Proceso de control de cambios 


Formulario de petition de cambios 


Proceso de registro de pruebas 



27.2 • Garantia de la calidad y estandares 593 



del manual que utilizaran sin cambio alguno, cuales se modificaran y cuales se dejaran de 
lado. Pueden tenerque crearse nuevos estandares para un requerimiento particular. Por ejem- 
plo, se pueden requerir estandares para la especificacion formal si no han sido utilizadas en 
proyectos anteriores. Conforme el equipo gana experiencia, se deberan modificary ampliar 
estos nuevos estandares. 



27.2.1 ISO 9000 

Un conjunto de estandares internacionales que se puede utilizar en el desarrollo de un siste- 
ma de gestion de calidad en todas las industrias es ISO 9000. Los estandares ISO 9000 pue- 
den aplicarse a un amplio abanico de organizaciones desde las de manufactura hasta las de 
servicios. ISO 9001 es el mas general de estos estandares y se aplica en organizaciones inte- 
resadas en el proceso de calidad de diseno, desarrollo y mantenimiento de productos. Un do- 
cumento de ayuda (ISO 9000-3) interpreta ISO 9001 para el desarrollo de software. Existen 
varios libros que describen el estandar ISO 9001 (Johnson, 1993; Oskarsson y Glass. 1995; 
Peach, 1996; Bamford y Deibler, 2003). 

ISO 9001 no es un estandar especifico para desarrollo de software, pero define principios 
generates que pueden aplicarse al software. El estandar ISO 9001 describe varios aspectos del 
proceso de calidad y define que estandares y procedimientos deben existir en una organiza- 
cion. Estos deben documentarse en un manual de calidad organizacional. La definicion del 
proceso debe incluirunadescripcion de ladocumentacion requerida, donde se demuestre que 
los procesos definidos han sido seguidos durante el desarrollo del producto. 

Los estandares ISO 9001 no definen tos procesos de calidad que deben usarse. De hecho, 
no restringe los procesos usados en una organizacion de ninguna forma. Esto permite flexi- 
bilidad en todos los sectores industriales e implicaquepequenas compaiiias puedan tenerpro- 
cesos no burocraticos y que cumplan con la normativa ISO 9000. Sin embargo, esta flexibili- 
dad implica que no podamos hacer suposiciones acerca del parecido o diferencia entre los 
procesos de compaiiias que cumplen con la normativa ISO 9000. La Figura 27.4 muestra las 
areas que abarca ISO 9001. Este libro no tiene suficiente espacio para exponereste estandar 
en profundidad. Ince (Ince, 1994) y Oskarsson y Glass (Oskarsson y Glass, 1995) dan deta- 
lles de como se puede utilizar el estandar para desarrollar procesos de gestion de calidad del 
software. La Figura 27.5 muestra las relaciones entre ISO 9000, el manual de calidad y los 
planes de calidad de proyectos particulares. Esta figura se ha creado a partir de un modelo del 
libro de Ince (Ince. 1994). 
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Los procesos de garantia de calidad en una organizacion se documentan en un manual de 
calidad que define el proceso de calidad. En algunos paises, autoridades acreditadas certifi- 
can que el proceso de calidad esta reflejado en el manual de calidad y es conforme al estan- 
dar ISO 9001 . Cada vez mas, los clientes buscan el certificado ISO 9000 como indicador de 
la seriedad con la que el proveedor ve la calidad. 

Algunas personas piensan que la certificacion ISO 9000 significa que la calidad del soft- 
ware producido por las compafiias certificadas sera mejor que la del de las compaflias no cer- 
tificadas. Este no es ciertamente el caso. El estandarlSO 9000 se refiere simplemente a lade- 
finicion de los procedimientos que son utilizados en la compaflia y la documentacion asociada 
que muestre que los procesos han sido seguidos. Este no se ocupa de asegurar que estos pro- 
cesos sean la mejor practica, ni asegura la calidad del producto. 

Por lo tanto, una compaflia puede definir sus procedimientos para la prueba del producto, 
que realice una prueba incompleta del software. Si estos procedimientos son seguidos y do- 
cumentados, la compaflia podria conseguir el estandarlSO 9001 . Mientras esta situacion es 
inverosimil, no hay duda de que algunos estandares de companias son bastante flojos y hacen 
solo una pequefia contribucion a la calidad del software. 



27.2.2 Estandares de documentacion 

Los estandares de documentacion en un proyecto de software son documentos muy impor- 
tantes ya que son la unica forma tangible de representar al software y su proceso. Los docu- 
mentos estandarizados tienen una apariencia, estructura y calidad consistentes y, por lo tan- 
to, son mas faciles de leery de comprender. 

Existen tres tipos de estandares de documentacion: 

1. Estandares del proceso de documentacion. Definen el proceso a seguir para la pro- 
duccion del documento. 

2. Estandares del documento. Gobiernan la estructura ypresentacionde los documentos. 

3. Estandares para el intercambio de documentos. Aseguran que todas las copias elec- 
tronicas de los documentos sean compatibles. 
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Los estandares del proceso de documentacion definen el proceso utilizado paraprodu- 
cir los documentos. Esto implica definir los procedimientos involucrados en el desarrollo 
del documento y las herramientas de software utilizadas. Tambien definen procedimien- 
tos de comprobacion y refinamiento que aseguren que se produzcan documentos de alta 
calidad. 

Los estandares de calidad del proceso de documentos deben ser flexiblesy lesdebe serpo- 
sible ajustarse a todos los tipos de documentos. Para los documentos de trabajo o memoran- 
dum, no es necesario comprobar explicitamente la calidad. Sin embargo, si los documentos 
son documentos formales utilizados para desarrollos posteriores o son documentos para en- 
tregara los clientes, se debe adoptarun proceso formal de calidad. La Figura27.6 muestraun 
modelo de uno de los posibles procesos de documentacion. 

Crearun borrador, comprobarlo, revisarlo y rehacerlo es un proceso iterative Este conti- 
nua hasta que se produce un documento de calidad aceptable. El nivel de calidad aceptable 
depende del tipo de documento y de los lectores potenciales de este. 

Los estandares de documento se aplican a todos documentos producidos en el transcurso 
del desarrollo de software. Los documentos deben tener un estilo y una apariencia consistentes 
y los documentos del mismo tipo deben tener una estructura consistente. Aunque los estan- 
dares del documento se adapten a las necesidades de un proyecto especifico, una buena prac- 
tica es que se utilice el mismo estilo en todos documentos producidos por una organizacion. 

Algunos ejemplos de estandares de documentos adesarrollarson: 

1. Estandares de identification de documentos. Puesto que los proyectos de sistemas 
grandes producen cientos de documentos, cada documento debe identificarse de for- 
ma unica. Para los documentos formales, este identificador es el identificador formal 
definido por el gestor de configuraciones. Para documentos informales, el estilo del 
identificador del documento es definido por el gestor del proyecto. 

2. Estandares de la estructura del documento. Cada clase de documentos producida 
durante un proyecto de software debe seguir alguna estructura estandar. Los 
estandares de estructura deben definir las secciones a incluir y especificar las con- 
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venciones utilizadas para la numeracion de paginas, el encabezado de las paginas y 
la informacion de los pies de pagina, asi como la numeracion de secciones y sub- 
secciones. 

3. Estdndares de presentation de documentos. Estos estandares definen un «estilo pro- 
pio» para los documentos y contribuyen notablemente a la consistencia de estos. In- 
cluyen la definicion de tipos de letra y estilos utilizados en el documento, la utiliza- 
cion de logotipos y los nombres de la compania, la utilizacion de color para resaltar la 
estructura del documento, etcetera. 

4. Estdndares para actualizar los documentos. Conforme el documento evoluciona y re- 
fleja los cambios en el sistema, se debe utilizaruna forma consistente para indicar los 
cambios en el documento. Se pueden utilizardiversos colores de laportada para indi- 
car una nueva version del documento y poner marcas en el margen para indicar parra- 
fos modificados o agregados. 

Los estandares de intercambio de documentos son importantes debido a que se pueden in- 
tercambiar copias electronicas de los documentos. La utilizacion de estandares de intercambio 
permite que los documentos se transfieran electronicamente y puedan reconstruirse en su for- 
ma original. 

Suponiendo que la utilizacion de herramientas estandares obligatoria en los estandares del 
proceso, los de intercambio definen las convenciones para emplear estas herramientas. Ejem- 
plos de estandares de intercambio son la utilizacion de una hoja de estilo estandar cuando se 
emplea un procesador de textos o las limitaciones en el uso de macros para evitar infecciones 
de virus. Los estandares de intercambio tambien delimitan los tipos de letra y los estilos del 
texto utilizados debido a los diversos recursos de visualizacion e impresion. 

273 Planificacion de la calidad 

La planificacion de la calidad es el proceso en el cual se desarrolla un plan de calidad para 
un proyecto. El plan de calidad define la calidad del software deseado y describe como va- 
lorar esta. Por lo tanto, define lo que es software de «alta calidad». Sin esta definicion, los 
diferentes ingenieros pueden trabajar en direcciones opuestas para optimizar los atributos de 
proyecto. 

El plan de calidad selecciona los estandares organizacionales apropiados para un produc- 
to y un proceso de desarrollo particulares. Si el proyecto utiliza nuevos metodos y herra- 
mientas, se tienen que definir nuevos estandares. Humphrey (Humphrey, 1989), en su libro 
clasico sobre gestion del software, sugiere una estructura para un plan de calidad. Esta es- 
tructura comprende: 

1. Introduction delproducto. Contiene la descripcion del producto, el mercado al que se 
dirige y las expectativas de calidad. 

2. Planes de producto. Contiene las fechas de terminacion del producto y las responsa- 
bilidades importantes junto con los planes para la distribucion y el servicio. 

3. Descripciones del proceso. Contiene los procesos de desarrollo y de servicio a utili- 
zarparael desarrollo y administracion del producto. 

4. Metas de calidad. Contiene las metas y planes de calidad para el producto, incluyendo 
la identificacion yjustificacion de los atributos de calidad importantes del producto. 

5. Riesgosy gestion de riesgos. Contiene los riesgos clave que podrian afectara la cali- 
dad del producto y las acciones para abordar estos riesgos. 
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Los planes de calidad obviamente difieren dependiendo del tamaflo y del tipo de sistema 
que se desarrolle. Sin embargo, cuando se redactan los planes de calidad, es necesario tratar 
de mantenerlos lo mas compactos posible. Si el documento es muy grande, los ingenieros no 
lo leeran y esto frustra el proposito de producir un plan de calidad. 

Existe una amplia variedad de atributos de calidad del software potenciales (vease la F i - 
gura 27.7) a considerar en el proceso de planificacion de la calidad. En general, no es po- 
sible optimizar todos los atributos para un sistema. El plan de calidad define los atributos 
de calidad mas importantes para el producto a desarrollar. Puede ser que la eficacia sea pri- 
mordial, por lo que sera necesario sacrificar otros factores para alcanzarla. Esto se estable- 
ce en el plan, y los ingenieros que trabajan en el desarrollo deben cooperar para lograrlo. 
El plan tambien define el proceso de evaluacion de la calidad. Es una forma estandar de va- 
lorar si algun atributo de calidad, como la mantenibilidad o la robustez, esta presente en el 
producto. 



2 7.4 Control de la calidad 

El control de la calidad implica vigilarel proceso de desarrollo de software para asegurarque 
se siguen los procedimientos y los estandares de garantia de calidad. Como ya se indico en 
este capitulo (vease la Figura 27. 1), en el proceso de control de calidad del proyecto se com- 
pruebaque las entregas cumplan los estandares definidos. 

Existen dos enfoques complementarios que se utilizan para comprobar la calidad de las en- 
tregas de un proyecto: 

1 . Revisiones de la calidad donde el software, su documentacion y los procesos utiliza- 
dos en su desarrollo son revisados porun grupo de personas. Se encargan de compro- 
bar que se han seguido los estandares del proyecto y el software y los documentos con- 
cuerdan con estos estandares. Se toma nota de las desviaciones de los estandares y se 
comunican al gestor del proyecto. 

2. Valoracion automatica del software en la que el software y los documentos produci- 
dos se procesan por algun programa y se comparan con los estandares que se aplican 
a ese proyecto de desarrollo en particular. Esta valoracion automatica comprende una 
medida cuantitativa de algunos atributos del software. La medicion y las metricas del 
software se estudian en la Seccion 27.5. 



27.4.1 Revisiones de la calidad 

Las revisiones son el metodo mas utilizado para validar la calidad del un proceso o de un pro- 
ducto. Involucran a un grupo de personas que examinan todo o parte del proceso software, los 
sistemas o su documentacion asociadapara descubrirproblemas potenciales. Las conclusio- 
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nes de la revision se registrar! formalmente y se pasan al autor o a quien sea responsable de 
corregir los problemas descubiertos. 

La Figura 27.8 describe brevemente varios tipos de revisiones, entre ellas las revisiones de 
gestion de la calidad. Las inspecciones ya se trataron en el Capitulo 22. Las revisiones de pro- 
greso son parte del proceso de gestion analizado en el Capitulo 5. Los diversos procesos de 
revision tienen muchas cosas en comun, y en el Capitulo 22 se describio el proceso para es- 
tablecer una revision. 

El equipo de revisiones debe tenerun nucleo de tres o cuatro personas como revisores prin- 
cipales. Uno debe ser el diseflador principal, el cual tendra la responsabilidad de tomar las de- 
cisiones tecnicas. Los revisores principales pueden invitar a otros miembros del proyecto, 
como a los disefiadores de los subsistemas, para que colaboren en la revision. Ellos no se in- 
volucran en la revision de todo el documento. Mas bien, se concentran en aquellas partes que 
afectan a su trabajo. De forma alternativa, el equipo de revision hace circular el documento a 
revisar y solicita comentarios escritos de otros miembros del proyecto. 

Los documentos a revisar deben distribuirse con anterioridad a la revision para dar tiem- 
po a los revisores a que los lean y los comprendan. Aunque esto puede interrumpir el proce- 
so de desarrollo, la revision no es eficaz si el equipo de revision no comprende adecuadamente 
los documentos antes de que tenga lugar la revision. 

La revision misma es relativamente corta (dos horas a lo mas). El autor del documento en 
revision debe seguir el documento junto con el equipo de revision. Un miembro del equipo 
preside la revision y otro registra formalmente todas las decisiones de la revision. Durante 
esta, el presidente es responsable de asegurar que se consideren todos los comentarios escri- 
tos. El responsable de la revision firmara el registrode la reunion, donde apareceran todos los 
comentarios y las decisiones tomadas. Este registro pasara a formar parte de la documenta- 
cion formal del proyecto. Si solo se descubren problemas menores, no es necesaria ninguna 
revision adicional. El presidente es responsable de asegurar que se hagan todos los cambios 
requeridos. Si se requieren cambios importantes, habra que hacer un seguimiento posterior de 
la revision. 

27.5 Medicion y metricas del software 

Las revisiones de la calidad son caras, consumen tiempo e inevitablemente retrasan la entre- 
ga del software. Idealmente, seria posible acelerar el proceso de revision utilizando herra- 
mientas que procesaran el diseno del software o el programa, e hiciesen valoraciones auto- 
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maticas de la calidad del software. Estas valoraciones permiten comprobar que el software tie- 
ne el umbral de calidad requerido, y destacar las partes en las cuales no se ha alcanzado para 
revisarlas. 

La medicion del software se refiere a derivar un valor numerico desde algun atributo del 
software o del proceso software. Comparando estos valores entre sly con los estandares apli- 
cados en la organizacion, es posible sacar conclusiones de la calidad del software o de los pro- 
cesos para desarrollarlo. Por ejemplo, supongamos que una organizacion hace planes para 
introducir una nueva herramienta de prueba de software. Antes de introducir la herramienta, 
se registra el numero de defectos descubiertos en el software en un tiempo dado; despues de 
introducir la herramienta, se repite este proceso. Si se descubren mas defectos en la misma 
cantidad de tiempo despues de introducir la herramienta, entonces pareceria que provee una 
informacion util para el proceso de validacion del software. 

Las mediciones del software pueden utilizarse para: 

1 . Hacer predicciones generates acerca del sistema. Haciendo mediciones de las carac- 
teristicas de los componentes del sistema y reuniendo estas, podremos derivar una es- 
timacion general de algunos atributos del sistema, como el numero de fallos. 

2. Identificar componentes andmalos. Mediante las mediciones podemos identificar los 
componentes que se salgan de lo normal. Por ejemplo, podemos medir los compo- 
nentes para identificar los de complejidades mas altas, los cuales suponemos que se- 
ran los que tengan mas errores, para centramos en ellos en el proceso de revision. 

Una metrica de software es cualquier tipo de medida relacionada con un sistema, proceso 
o documentacion de software. Algunos ejemplos son las medidas que se utilizan para calcu- 
lar el tamano de un producto en lineas de codigo; el indice de Fog (Gunning, 1962), que mide 
la claridad de un parrafo en un texto; el numero de fallos encontrados en un producto soft- 
ware entregado; y el numero de personas/dia requeridas para desarrollar un componente del 
sistema. 

Algunas compafnas como Hewlett-Packard (Grady, 1993), AT&T (Barnard y Price, 1994) 
y Nokia (Kilpi, 2001) han introducido programas de metricas que recogen medidas en sus pro- 
cesos de gestion de calidad. El enfoque fue recoger medidas de los defectos en los programas 
y en los procesos de verificacion y de validacion. Offen y Jeffrey (Offen y Jeffrey, 1997) y 
Hall y Fenton (Hall y Fenton, 1997) estudian la introduccion de tales programas en la indus- 
tria. El manual ami (aplicacion de metricas en la industria) (Pulford etal., 1996) daconsejos 
detallados sobre la medicion para la mejora de procesos. 

Sin embargo, pocas compafnas utilizan sistematicamente metricas para valorar la cali- 
dad del software. Una razon de esto es que, en mucha companias, los procesos de softwa- 
re estan definidos y controlados, y no son lo suficientemente maduros para utilizar medi- 
das. Otra razon es que no existen estandares para las metricas y, por lo tanto, las 
herramientas para recogida y analisis de datos son muy limitadas. Muchas companias no 
estaran dispuestas a introducir mediciones hasta que esten disponibles tales estandares y 
herramientas. 

Las metricas son de control o de prediccion. Ambas pueden influir en la toma de decisio- 
nes de gestion como muestra la Figura 27.9. Las metricas de control suelen estar asociadas 
con los procesos, mientras que las metricas de prediccion lo estan a los productos. Ejemplos 
de las metricas de control o de procesos son el esfuerzo y el tiempo promedio requeridos para 
reparar los defectos encontrados. Ejemplos de metricas de prediccion son la complejidad ci- 
clomatica de un modulo, la longitud media de los identificadores de un programa, y el numero 
de atributos y operaciones asociadas con los objetos de un diseno. En este capitulo, tratare- 
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mos las metricas de prediccion, ya que nos centraremos en las medidas para predecir la cali- 
dad del producto. En el Capitulo 28 veremos las metricas de control. 

Frecuentemente, es imposible medir los atributos de calidad del software directamente. Los 
atributos de calidad como la manten ibilidad, lacomprensiony lausabilidad son atributos ex- 
ternos que nos dicen como ven el software los desarrolladores y los usuarios. Estos se ven 
afectados por diversos factores y no existe un camino simple para medirlos. Mas bien es ne- 
cesario medir atributos internos del software (como su tamano) y suponer que existe una re- 
lacion entre lo que queremos medir y lo que queremos saber. De forma ideal, existe una rela- 
cion clara y valida entre los atributos internos y externos del software. 

La Figura 27.10 muestra algunos atributos externos de la calidad que nos seran interesantes 
y los atributos internos relativos a ellos. El diagrama sugiere que existe una relacion entre los 
atributos externos y los internos, pero no dice que relacion es. Para que la medida del atributo 
interno seaun indicador util de lacaracteristica externa, se deben cumplirtres condiciones: 

1 . El atributo interno debe medirse de forma precisa. 

2. Debe existir una relacion entre lo que se puede medir y el atributo de comportamien- 
to externo. 

3. Esta relacion se comprende, ha sido validada y se puede expresar en terminos de una 
formula o modelo. 
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La formulacion del modelo comprende identificar la forma funcional del modelo (lineal, 
exponencial, etc.) atraves del analisis de los datos recogidos, identificar los parametros que 
se van a incluir en el modelo y calibrarlos utilizando datos existentes. El desarrollo del mo- 
delo, si se confiaenel, requiereque se tengaexperienciaentecnicasestadisticas e, idealmente, 
alguien con experiencia y conocimientos debe definir el modelo. 



La Figura 27.1 1 muestra el proceso de medicion del software dentro de un proceso de control 
de calidad. Cada uno de los componentes del sistema se analiza por separado y los diversos 
valores de las metricas se comparan entre si y, quizas, con los datos historicos de medicion 
recogidos en los proyectos previos. Las medidas anomalas se utilizan para centrar el esfuer- 
zo de garantia de calidad en los componentes que tienen problemas de calidad. 
Los pasos clave en este proceso son: 

1. Seleccionar las medidas a realizar. Se deben formular las preguntas que la medic ion 
intenta responder y definir las mediciones requeridas para resolver estas preguntas. No 
se recogen las mediciones que no estan relacionadas de forma directa con estas pre- 
guntas. El paradigma GQM (Goal-Question-Metric) de Basili (Basili y Rombach, 
1988), que se analiza en el capitulo siguiente, es un buen enfoque autilizar cuando se 
decide que datos se deben rccolcctar. 

2. Seleccionar los componentes a evaluar. No es necesario o deseable estimar los valo- 
res de las metricas de todos los componentes de un sistema software. En algunos ca- 
sos, para la medicion se elige un conjunto representative de componentes. En otros, 
se evaluan los componentes particularmente criticos como son los fundamentales que 
se utilizan de forma constante. 

3 . Medir las caracteristicas de los componentes. Se miden los componentes selecciona- 
dos y se calculan los valores de las metricas. Normalmente, esto comprende procesar 
la representacion del componente (diseflo, codigo, etc.) utilizando una herramienta de 
recogida de datos. Esta herramienta se puede crear de forma especial o puede estar in- 
corporada en las herramientas C A S Eutilizadas en laorganizacion. 

4. Identificar las mediciones anomalas. Una vez que se obtienen las mediciones de los 
componentes, se comparan entre si y con las mediciones previas registradas en una 
base de datos de mediciones. Se deben observar los valores mas altos y los mas bajos 
de cada metrica, puesto que estos sugieren que puede haber problemas con los com- 
ponentes que exhiben estos valores. 

5. Analizar los componentes andmalos. Una vez identificados los componentes con valo- 
res anomalos para las metricas particulares, se examinan estos componentes para decidir 
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si los valores de la metrica indican que la calidad del componente esta en peligro. Los va- 
lores de la metrica anomalos para la complejidad (por ejemplo) no significan necesaria- 
mente que el componente tenga una calidad deficiente. Puede haber alguna otra razon 
para ese valor alto y ello no significa que existan problemas con la calidad del producto. 

Los datos recogidos se mantienen como un recurso organizacional y deben conservarse re- 
gistros historicos de todos los proyectos aun cuando los datos no se hayan utilizado durante 
en un proyecto particular. Una vez que se haya creado una base de datos suficientemente gran- 
de de mediciones, se hace lacomparacionde los proyectos, y las metricas especificas se refi- 
nan de acuerdo con las necesidades organizacionales. 

27.5.2 Metricas de producto 

Las metricas de producto se refieren a las caracteristicas del software mismo. Desafor- 
tunadamente, las caracteristicas del software que se miden facilmente, como el tamano y la 
complejidad ciclomatica, no tienen una relacion claray consistente con los atributos de cali- 
dad como la compresion y la mantenibilidad. Las relaciones varian dependiendo de los pro- 
cesos, la tecnologia y el tipo de sistemas a desarrollar. Las organizaciones interesadas en la 
medicion tienen que construiruna base de datos historicos. Despues, esta se puede utilizar 
para descubrircomo se relacionan los atributos del producto de software con la calidad en la 
que esta interesada laorganizacion. 

Las metricas del producto se dividen en dos clases: 

1 . Las metricas dindmicas, que son recogidas por las mediciones hechas en un progra- 
ma en ejecucion. 

2. Las metricas estdticas, que son recogidas por las mediciones hechas en las represen- 
taciones del sistemacomo el diseno, el programa o la documentacion. 

Estas diferentes metricas estan relacionadas con diversos atributos de calidad. Las metricas 
dinamicas ayudan a valorar la eficiencia y la fiabilidad de un programa. Las metricas estaticas 
ayudan a valorar la complejidad, la comprensiony la mantenibilidad de un sistema de software. 

Las metricas dinamicas por lo general estan relacionadas de forma cercana con los atribu- 
tos de calidad del software. Es relativamente facil medirel tiempo de ejecucion requerido por 
funciones particulares y estimar el tiempo requerido para iniciar un sistema. Esto se relacio- 
na directamente con la eficiencia del sistema. De forma similar, se puede registrar el numero 
y el tipo de caidas del sistema y relacionarlos directamente con la fiabilidad del software como 
se indico en el Capitulo 24. 

Las metricas estaticas, porotro lado, tienen una relacion indirecta con los atributos de ca- 
lidad. Se han propuesto muchas de estas metricas y se han llevado a cabo experimentos para 
tratarde derivary validar las relaciones entre estas metricas y la complejidad, lacomprension 
y la mantenibilidad del sistema. LaFigura27.12 describe varias metricas estaticas utilizadas 
para valorar los atributos de calidad. De estas, parece serque los predictores mas confiables 
de lacomprension, la complejidad y mantenibilidad del sistema son la longituddel programa 
o del componente y la complejidad ciclomatica. 

Las metricas de laFigura27.12 son genericas, pero se han propuesto metricas especificas 
para la programacion orientada a objetos (Figura 27.13). Las metricas orientadas a objetos 
mas conocidas fueron propuestas por Chidamber y Kemerer (Chidamber y Kemerer, 1 994) y 
hay herramientas para recoger estas metricas. Algunas de estas metricas han derivado de las 
antiguas metricas de la Figura 27. 12, pero otras son metricas unicamente para sistemas orien- 
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Fan-in/Fan-out 


Fan-in es una medida del numero de funciones o metodos que llaman a otra fundon o me- 
todo (por ejemplo, X). Fan-out es el numero de funciones que son Hamadas por una fundon 
X. Un valor alto de fan signifies que X esta fuertemente acoplada al resto del disefto y que los 
cambios en X tendran muchos efectos importantes. Un valor alto de fan-out sugiere que la 
complejidad de X podrfa ser aha debido a la complejidad de la logics de control necesaria para 
coordinar los componentes llamados. 


Longitud del c6digo 


£sla es una medida del tamafto del programa. Ceneralmente, cuanto mis grande sea el la- 
maho del eddigo de un components mas complejo y susceptible de errores seri el compo- 
nerrte. La longitud del eddigo ha mostrado ser la metrica mis fiable para prededr errores en 
los componentes. 


Complejidad ciclomatica 


Esta es una medida de la complejidad del control de un programa. Esta complejidad del con- 
trol esta reladonada con la compression del programa. El calculo de la complejidad ddomi- 
tica se trata en el Capltulo 22. 


Longitud de los identificadores Es una medida de la longitud promedio de los drferentes iderrtrficadores en un programa. 

Cuanto mas grande sea la longitud de los identificadores, mas probable sent que tengan sig- 
nifies do; por lo tanto, el programa sera mas comprensible. 


Prof undidad del anidamiento Esta es una medida de la profundidad de anidamiento de las instrucdones condicionales «rf» 
de las condicionales en un programa. Muchas condiciones antdadas son drffdles de comprender y son potendal- 

mente susceptibles de errores. 


Indice de Fog 


Esta es una medida de la longitud promedio de las palabras y las frases en los documentos. 
Cuanto mas grande sea el (ndice de Fog, el documento seri mis dificil de comprender. 

Figura 27.12 Metricas estaticas de producto software. 

tados a objeto. El-Amam (El-Amam, 2001), en una excelente revision de las metricas orien- 
tadas a objetos, expone algunos de estos estudios y concluye que todavia no tenemos sufi- 
cientes evidencias para entender como se relacionan las metricas orientas a objeto con los atri- 
butos de calidad extemos del software. 

Las metricas relevantes dependen del proyecto, las metas del equipo de gestion de calidad 
y el tipo de software a desarrollar. Todas las metricas mostradas en las Figuras 27.12 y 27.13 




Profundidad del arbol 
de herencia 


Esta representa el numero de nhwles discretes en el arbol de herenda donde las subdases 
heredan atributos y operadones (metodos) de las superdases. Cuanto mis profundo sea el 
arbol de herenda, mas complejo sera el disefto. Muchas clases de objetos distJntas tienen que 
comprenderse para conocer las dases de objetos en las hojas del arbol. 


Metodo Fan-in/Fan-out 


EstS directamente reladonada fan-in y fan-out, como se describid antes, y signrfka esendat- 
menite lo rrusrno. Sin embargo, es conveniente haceruna distindon entre las llamadas prowenien- 
tes de otitis metodos dentro del objeto y las llamadas provenierrtes de los metodos extemos. 



Metodos pesados por clase Este es el numero de metodos induidos en una dase con su correspondientes pesos, que ven- 

dran dados por la complejidad de cada metodo. Por lo tanto, un metodo sendHo tiene una 
complejidad de 1 y un metodo grande y complejo un valor mucho mas grande. Cuanto mis 
grande sea el valor de esta metrica, la dase seri mas compleja. Los objetos complejos ben- 
den a ser mas drffdles de comprender. No son logfcamente cohesiros, por lo que no se pue- 
den reutilizar efectivamente como superdases en un irbol de herencia. 

Numero de operaciones Este es el numero de operadones en una superdase que se anulan en una subdase. Un va- 

sobrescritas lor afto para esta metrica indica que la superdase utilizada no es una madre adecuada para la 

subdase. 



Figura 27.13 Metricas orientadas a objetos. 
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pueden semos utiles en alguna situacion. De la misma manera, no seran apropiadas que en 
otras circunstancias. Cuando se introduce una medida de software como parte del proceso de 
gestion de calidad, las organizaciones deben hacer experimentos para descubrir que metricas 
son mas apropiadas para sus necesidades. 

27.5.3 Anallsls de las medlclones 

Uno de los problemas con la recogida de datos cuantitativos en el software y en los proyec- 
tos de software es comprender lo que significan realmente los datos. Es facil mal interpretar 
los datos y hacer inferencias incorrectas. Las mediciones se deben analizar cuidadosamente 
para comprender lo que realmente significan. 

Para ilustrar que los datos tornados se pueden interpretar de formas diferentes, considere- 
mos el siguiente escenario. Para hacer mas facil su comprension, se ha usado una metrica de 
producto en lugar de una de proceso, pero el mensaje final siempre es el mismo; las razones 
del cambio frecuentemente son dificiles de comprender. 

Un gestor decide supervisar el numero de peticiones de cambios solicitados por los clien- 
tes basandose en la suposicion de que existe una relacion entre estas peticiones de cambios y 
la utilidad y conveniencia del producto. Cuanto mas alto es el numero de peticiones de cam- 
bios, el software cumple menos las necesidades del usuario. 

Procesar las peticiones de cambios y cambiar el software es costoso. Por lo tanto, la orga- 
nizacion decide modificar su proceso para incrementar la satisfaccion del cliente y, al mismo 
tiempo, reducir los costes del cambio. Se pretende que los cambios en el proceso den como 
resultado mejores productos y menos peticiones de cambios. 

Los cambios en el proceso comienzan involucrando mas al cliente en el proceso de disefio 
de software. Se introducen las pruebas beta para todos los productos, y las modificaciones so- 
licitadas por los clientes se incorporan en el producto a entregar. Se entregan las nuevas ver- 
siones de los productos desarrollados con este proceso modificado. En algunos casos, el nu- 
mero de peticiones de cambios se reduce; en otros, se incrementa. El gestor se queda perplejo 
y no puede valorar los efectos de los cambios del proceso en la calidad del producto. 

Para comprender por que pasan estas cosas, se tiene que comprender por que se hacen las pe- 
ticiones de cambio. Una razon es que el software entregado no haga lo que los clientes quieren 
que haga. Otra posibilidad es que el software sea muy bueno y se utilice amplia y frecuente- 
mente, algunas veces parapropositos para los que no se diseno originalmente. Puesto que exis- 
ten muchas personas que lo utilizan, es natural que se generen mas peticiones de cambios. 

Una tercera posibilidad es que la compania de sarro lladora del software sea sensible a las 
peticiones de cambio de los clientes. Por lo tanto, los clientes se sienten satisfechos con el ser- 
vicio que reciben. Generan muchas peticiones de cambios debido a que conocen que esas pe- 
ticiones se consideraran seriamente. Sus sugerencias probablemente se incorporaran en las 
versiones posteriores del software. 

El numero de peticiones de cambios podria decrecer debido a que los cambios en el proceso 
han sido eficaces y lo han hecho mas utilizable y conveniente. De forma alternativa, este nume- 
ro podria haber decrecido debido a que el producto ha perdido mercado con respecto a su pro- 
ducto rival. En consecuencia, existen menos usuarios del producto. El numero de peticiones de 
cambios podria incrementarse debido a que existen mas usuarios, debido a que los procesos de 
pruebas beta han convencido a los usuarios de que la compania desea hacer cambios o debido a 
que los sitios de pruebas beta no son tipicos o no se utilizan mucho en el programa. 

Para analizar los datos de las peticiones de cambios, no basta con conocer el numero de 
peticiones de cambios. Es necesario conocer quien hizo lapeticion, como utilizael software 
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y por que hizo la peticion. Es necesario saber si existen factores extemos, como las modifi- 
caciones en el procedimiento de peticion de cambios o cambios en el mercado, que podrian 
tener algiin efecto. Con esta informacion, es posible descubrir si los cambios del proceso han 
sido eficaces para incrementar la calidad del producto. 

Esto ilustra que la interpretacion de datos cuantitativos de un producto o proceso es un pro- 
ceso subjetivo. Los procesos y productos para medir no estan aislados de su entorno y los cam- 
bios en ese entorno invalidan las comparaciones de los datos. Los datos cuantitativos de las 
actividades humanas no siempre pueden tomarse como valores de entrada. Las razones sub- 
yacentes al valor medido deben investigarse. 



PUNTOS CLAVE 

• La gesti on de la calidad del software permite senalarsieste tiene un escaso num erode defectosysi alcanza 
los estandares requeridosdemantenibilidad,Habilidad, portabilidad, etcetera. Las actividades de ta gesti on 
deta calidad comprendentagarantiade la calidad que establece tos esta nda res para et desarrollo de software, 
la planif icacion de la calidad y el control de la calidad que comprueba et software con respecto a los estan- 
dares definidos. 

• Un manual de calidad organizacional debe documentar un conjunto de procedimientos de garantia de la cali- 
dad. Este puede basarse en tos modelosgenericossugeridosenlosestandares ISO 9000. 

• Los estandares de software son importantes para garantizar ta calidad puesto que representan una identifi- 
caciondelas«mejorespracticas».Et proceso de control de calidad implica comprobarque el proceso del soft- 
ware yel software a desarrollar concuerdan con estos estandares. 

• Las revisiones de los productos a entregar por el proceso del software incumben a un equipo de personas los 
cuates comprobaranquese han seguido los estandares de calidad. Las revisiones son latecnicamasutiliza- 
da para valorar la calidad. 

• Las mediciones de software se utilizan para recoger datos cuantitativos acerca del software y sus procesos. 
Los valores de las metricas de software recogidas se utilizan para hacer inferencias de la calidad del produc- 
to y del proceso. 

• Las metricas de calidad del producto son de gran valor para resaltar tos componentes andmalos que tienen 
problemas de calidad. Estos componentes se deberan analizarcon mas detalle. 

• No existen metricas de software estandarizadas y aplicables umversalmente. Las organizaciones deben se- 
leccionar metricas y analizar mediciones basadas en el conocimiento y circunstancias locales. 



LECTURAS ADICIONALES H i A *&^BWMHRBWRB"UWBMM*'^m 

Software Quality Assurance: From Theory to Implementation. Una excelente y actualizada mirada a los principios y 
practicas de la garantia de la calidad. Incluye un estudio sobre los estandares ISO 9001. (D. Galin, 2004, Addison- 
WesLey.) 
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Metrics and Models for Software Quality Engineering, 2nded. Es una exposicion facil de comprender acerca de las 
metricas que incluyen el proceso software. Contiene las bases matematicas necesarias para el desarrollo y la com- 
prension de los modelos en los que se basan las mediciones del software. (S. H. Kan, 2003, Addison-Wesley.) 

"Making sense of measurement for small organisations". Este es un articulo interesante acerca de las aplicaciones 
practicas de las metricas. Senala que ia utilizacion de las metricas tiene que considerarsu contexto. (K. Kautz, IEEE 
Software, marzo-abril de 1999.) 

A Quantitative Approach to Software Management: The ami Handbook. Es una excelente guia acerca de como in- 
troduce un programa de medicidn y la utilizacion de los resultados para mejorar el proceso. Desafortunadamente, 
es dificil de encontrar. (K. Pulford etai, 1996, Addison-Wesley.) 



EJERCICIOS MHIHMfc, HbtlHHHHHMill 

27.1 Explique por que un proceso del software de alta calidad debe conducir a productos de software de alta 
calidad. Comente los posibles problemas con este sistema de gestidn de la calidad. 

272 Explique como deben utilizarse los estandares para captar la sabiduria organizacional acerca de sus me- 
todos de desarrollo de software efectivos. Indica cuatro tipos de conocimiento que deben recoger tos es- 
tandares organizacionales. 

27.3 Comente la valoracidn de la calidad del software de acuerdo con los atributos de calidad mostrados en la 
Figura 27.7. Explique como se podria evaluar cada uno de los atributos. 

27.4 Disehe un formulario electrdnico que se pueda utilizar para registrar los comentarios de la revision y para 
hacer comentarios a los revisores por medio del correo electrdnico. 

27.5 Describa brevemente los posibles estandares que se podrian utilizar para: 

• Estructuras de control en C, C++ o Java 

• Crear informes para un proyecto de fin de curso de una universidad 

• El proceso de realizary aprobar cambios a un programa (vease el Capitulo 29) 

• El proceso de comprar e instalar una computadora. 

27.6 Suponga que trabaja en una organizacidn que desarrolla productos de bases de datos para sistemas de 
microcomputadoras. Esta organizacidn est a interesada en cuantif icarsu desarrollo de software. Escribaun 
informe que indique las metricas apropiadasycdmo recoger estas metricas. 

27.7 Explique por que las metricas dedisenode software, por si mismas, son un m e tod o inadecuado para pre- 
decir la calidad del diseno. 

27.8 Consulte la literatura y encuentre otras metricas de calidad para el diseno sugeridas, ademas de las co- 
mentadas aqui. Considere estas metricas en detalle y evalue si conducen a valores reales. 

27.9 Explique por que es dificil validar las relaciones entre los atributos internos del software, como la com- 
plejidad ciclomatica.ylos atributos externos, como la mantenibilidad. 

27.10 iCdmo podrian utilizarse las mediciones auto in a t i c a s en programacidn extrema? (vease el Capitulo 17). 

27.11 iFrenan los estandares software la innovacion tecnoldgica? 

27.12 Un colega que es un buen programador produce software con un numero bajo de defectos, pero frecuen- 
temente prescindede los estandaresde calidad organizacionales. ^Cdmodeberian losadministradoresde 
la organizacidn reaccionara este comportamiento? 
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Mejora 
de procesos 



Objetivos 

□ objetivo de este capitulo es explicar como se pueden mejorar 
los procesos del software para obtener el mejor producto- Cuando 
termine de leer este capitulo: 

• comprendera los principios de mejora de procesos del software 
y por que vale la pena esta mejora; 

• comprendera como los factores del proceso del software 
influyen en la calidad del software y en la productividad de los 
desarrolladores; 

• sera capaz de desarrollar modelos simples de procesos de 
desarrollo de software; 

• entendera las nociones de capacidad y madurez de proceso, y 
el marco general del modelo CMMI para la mejora de procesos. 

Contenidos 

28.1 Calidad de producto y de proceso 

28.2 Clasificacion de los procesos 

28.3 Medicion del proceso 

28.4 Anal isis y modelado de procesos 

28.5 Cambio en los procesos 

28 . 6 El marco de trabajo para la mejora de procesos CMMI 
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Como vimos en el Capitulo 27, existe un vinculo estrecho entre la calidad del proceso de 
desarrollo y la calidad de los productos desarrollados utilizando dicho proceso. En con- 
secuencia, muchas companias de ingenieria del software han tornado el camino de la me- 
jora de los procesos del software para mejorar su software. La mejora de procesos signi- 
fica entender los procesos existentes y cambiarlos para mejorar la calidad del producto 
y/o reducir los costes y el tiempo de desarrollo. Mucha de la literatura sobre mejora de 
procesos se ha centrado en la optimizacion de los procesos para mejorar la calidad del 
producto y, en particular, en reducir el numero de defectos en el software entregado. Una 
vez que se logra esto, las metas principales son la reduccion de costes y tiempo de de- 
sarrollo. 

Los procesos del software son intrinsecamente complejos y comprenden un gran numero 
de actividades. Como los productos, los procesos tambien tienen atributos o caracteristicas 
como se puede veren la Figura 28.1. No es posible hacer mejoras de procesos que optimicen 
todos los atributos del proceso de forma simultanea. Por ejemplo, si se requiere un proceso 
de desarrollo rapido, entonces es necesario reducir la visibilidad del proyecto. Hacer un pro- 
ceso visible significa producir documentos a intervalos regulares. Y esto hace que inevita- 
blemente el proceso sea lento. 

La mejora de procesos no significa simplemente adoptar metodos o herramientas particu- 
lars o utilizar algun modelo de un proceso utilizado en lugar de otro. Aunque las organiza- 
ciones que desarrollan el mismo tipo de software claramente tienen mucho en comun, siem- 
pre existen factores organizacionales particulars, procedimientos y estandares que influyen 
en el proceso. Raramente se tendra exito cambiando simplemente a un proceso utilizado en 
otro lugar. Debe verse la mejora de procesos como una actividad especifica de una organiza- 
cion o de parte de ella si es una organizacion grande. 

La mejora de procesos es una actividad ciclica, tal como muestra la Figura 28.2. Y tiene 
tres estados principales: 

1. Proceso de medicion de los atributos del proyecto actual o del producto. El objetivo 
es mejorar las mediciones de acuerdo con las metas de la organizacion involucrada en 
el proceso de mejora. 





Comprensi6n 


iHasta que punto se define completamente el proceso y como de ficil es 
comprender su definition? 


Visibilidad 


LIm actividades del proceso culminan en resurtados daros de forma que 
el progreso del proceso es visible extemamente? 


Apoyo 


Masta que punto las actividades del proceso pueden apoyarse en herra- 
mientas case? 


AceptackSn 


t£l proceso definido es aceptable y utilizable por los ingenieros respon- 
sables de producir el software? 


Rabilklad 


l£\ proceso disenado es de tal forma que los errores del proceso se evi- 
tan o identrfican antes de que se conviertan en errores de producto? 


Robustez 


iPuede continuar el proceso a pesar de los proMemas inesperados? 



Mantenibilidad iPuede evolucionar el proceso para reflejar los requerirniento s organiza- 

tionales cambiantes o las mejoras identjfkadas del proceso? 



Caracteristicas 
de los procesos. 



Rapid** 



f£6mo,de (Apido se puede compktar el preeamddedConsJniedOA de un 
ststema a partif de una wpodftwactn daia? 
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Figura 28.2 

El ciclo de mejora 

de procesos. 




2. Proceso de analisis. El proceso actual es valorado, y se identifican puntos flacos y cue- 
llos de botella. En esta etapa se suelen desarrollar los procesos que describen los mo- 
delos de proceso. 

3. Introduccion de los cambios del proceso identificados en el analisis. 

Cada una de estas secciones es cubierta en secciones separadas de este capitulo. Cada eta- 
pa del proceso puede durar varios meses. La mejora de procesos es una actividad a largo pla- 
zo. Es una actividad continua, en la que se introducen nuevos procesos, el entorno de nego- 
cio cambia y los procesos por si mismos evolucionan para tener en cuenta estos cambios. 

28.1 Calidad de producto y de proceso 

La mejora de procesos esta basada en la suposicion de que la calidad del proceso de desarro- 
llo es critica para la calidad del producto. Estas nociones de mejora de procesos provienen del 
ingeniero estadounidense W. E. Deming, quien trabajo en la industriajaponesa despues de la 
Segunda Guerra Mundial para mejorar la calidad. La industriajaponesa habia estado dedica- 
da al proceso de mejora continua de procesos durante muchos aiios. Esto contribuyo enor- 
memente a la calidad de los bienes manufacturados japoneses. 

Deming yotros introdujeron la ideade control estadistico de la calidad. Esta se basaenme- 
dir el numero de defectos en los productos y relacionar estos defectos con el proceso. Este se 
mejora con el proposito de reducir el numero de defectos en el producto y hasta que sea re- 
petible; esto es, hasta que los resultados del proceso sean predecibles y el numero de defec- 
tos se reduzca. Despues se estandariza e inicia un ciclo de mejoras de calidad. 

Humphrey, en su libro fundamental sobre gestion de procesos (Humphrey, 1988). comen- 
ta que las mismas tecnicas pueden ser aplicadas a la ingenieria del software. El escribio: 

W. E. Deming, en su trabajo con ;a industria japonesa despues de la Segunda Guerra 
Mundial, aplico los conceptos de control estadistico de procesos a la industria. A unque 
hay diferencias intportantes, estos conceptos son aplicables al software al igual que si 
fuesen caches, cdmaras, relojes o acero. 

Aunque hay claras similitudes, aqui mostramos desacuerdo con Humphrey en que los re- 
sultados de la ingenieria de la industria manufacturera puedan ser transferidos directamente 
a la ingenieria del software. Cuando existe manufactura, la relacion entre proceso y produc- 
to es obvia. Mejorar un proceso de tal forma que se eliminen los defectos conduce a mejores 
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productos. Este vinculo es menos obvio cuando el producto es intangible y dependiente, y de 
cierta forma podemos decir que los procesos intelectuales no se pueden automatizar. La cali- 
dad del software no depende de un proceso de manufacture sino de un proceso de disefio en 
el que las capacidades del individuo son importantes. Para algunas clases de productos, el pro- 
ceso utilizado es el determinante mas importante de la calidad del producto. Sin embargo, para 
aplicaciones innovadoras en particular, la gente involucrada en el proceso es mas importante 
que el proceso utilizado. 

Para los productos software, o para cualquier otro producto intelectual como libros o peli- 
culas donde la calidad del producto depende del disefio, existen cuatro factores que afectan a 
la calidad del producto. Estos se muestran en la Figura 28.3. 

La influencia de cada uno de estos factores depende del tamafio y del tipo de proyecto. Para 
sistemas muy grandes compuestos de subsistemas independientes, desarrollados por equipos 
que pueden trabajar en diferentes localizaciones, el determinante principal de la calidad del 
producto es el proceso del software. Los problemas principales con los proyectos grandes son 
la integracion, lagestion y las comunicaciones. Por lo general existe unamezclade habilida- 
des y de experiencia en los miembros del equipo y, puesto que el proceso de desarrollo re- 
quiere varios afios, el equipo de desarrollo es volatil. Puede cambiar totalmente en el tiempo 
de vida del proyecto. Por lo tanto, los individuos con talento y habilidades particulares por lo 
general no tienen un efecto dominante en el tiempo de vida del proyecto. 

Sin embargo, para proyectos pequefios donde existen unicamente unos pocos miembros, 
la calidad del equipo de desarrollo es mas importante que el proceso de desarrollo utilizado. 
Si el equipo tiene un nivel alto de habilidad y experiencia, la calidad del producto probable- 
mente sea alta. Si el equipo no tiene experiencia y habilidades, un buen proceso delimita el 
dafio, pero no conducira, por si mismo, a software de alta calidad. 

Si los equipos sonpequefios, es importante contarconunabuenatecnologiade desarrollo. 
El equipo no puede dedicar mucho tiempo aprocedimientos administrativos tediosos. Los in- 
genieros invierten mucho de su tiempo disefiando y programando el sistema, por lo que las 
buenas herramientas afectan de forma importante a su productividad. Para proyectos grandes, 
un nivel basico de tecnologia de desarrollo es esencial para la gestion de la informacion. Sin 
embargo, de forma paradoj ica, las sofisticadas herramientas CASE son en general menos im- 
portantes. Los miembros del equipo invierten relativamente poco tiempo en las actividades de 
desarrollo y mas en comunicarse y comprender las otras partes del sistema. Este es el factor 
dominante que afecta a su productividad. Las herramientas de desarrollo no son significati- 
vas en este caso. 

La base del rectangulo de la Figura 28.3 es absolutamente critica. La calidad del pro- 
ducto se ve afectada si un proyecto, independientemente de su tamafio, esta mal presu- 
puestado o planificado con un tiempo de entrega irreal. Un buen proceso requiere recursos 




Figura 28.3 
Principales factores 
de calidad del 
producto software. 
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para su implementacion efectiva. Si estos recursos son insuficientes, el proceso no puede 
desarrollarse de forma efectiva. Si los recursos no son adecuados, solo las personas excelen- 
tes pueden salvar el proyecto. Mas aun, si el deficit es demasiado grande, la calidad del pro- 
ducto se degradara. 

A menudo, la causa real de los problemas en la calidad del software no es la mala gestion, 
los procesos inadecuados o la poca calidad de la capacitacion. Mas bien, es el hecho de que 
las organizaciones deben competirpara sobrevivir. Muchos proyectos de software infravalo- 
ran el esfuerzo o prometen una entrega rapida con el fin de conseguir el contrato de desarro- 
llo. En un intento de mantener estos compromisos, la compania podria sacrificar la calidad 
del software. 

28.2 Clasificacion de los procesos 

Existen procesos de software en todas las organizaciones, desde empresas unipersonales has- 
ta grandes multinacionales. Estos procesos son de diferentes tipos dependiendo del grado de 
formalizacion del proceso, los tipos de productos desarrollados y el tamano de la organiza- 
cion, entre otros. Hay cuatro clases de procesos software: 

1. Procesos informales. Son procesos en los que no existe un modelo de proceso defini- 
do de forma estricta. El proceso utilizado es elegido por el equipo de desarrollo. Los 
procesos informales podrian utilizar procedimientos formales, como la gestion de 
configuraciones, pero los procedimientos a utilizar y sus relaciones son definidos por 
el equipo de desarrollo. 

2. Procesos gestionados. Se utiliza un modelo de proceso para dirigir el proceso de des- 
arrollo. El modelo de proceso define los procedimientos, su agenda y las relaciones en- 
tre los procedimientos. 

3. Procesos metodoldgicos. Se utiliza algun o algunos metodos de desarrollo definidos 
(como los metodos sistematicos para diseno orientado a objetos). Estos procesos se be- 
nefician de la existencia de herramientas CASE para el diseno y el analisis. 

4. Procesos de mejora. Son procesos que tienen inherentemente objetivos de mejora. 
Existe un presupuesto especifico para estos procesos de mejora, y de procedimientos 
para introducir tales mejoras. Como parte de estas mejoras, se introducen mediciones 
cuantitativas del proceso. 

Estas clasificaciones se solapan, por lo que un proceso puede ser de diferentes clases. Por 
ejemplo, el proceso puede ser informal en el sentido de que es seleccionado por el equipo de 
desarrollo. El equipo puede optar porusarun metodo de diseno particular. Tambien tiene la 
capacidad de mejora de procesos. En este caso, el proceso se clasificaria como informal, me- 
todologico y de mejora. 

Esta clasificacion es util debido a que sirve como base para la mejora de procesos multi- 
dimensional. Ayuda a las organizaciones a elegirun proceso de desarrollo apropiado para los 
diferentes productos. La Figura 28.4 muestra los diferentes tipos de procesos que se podrian 
utilizarpara el desarrollo de diferentes tipos de productos, En la figura no se muestran los pro- 
cesos de mejora, ya que cualquier tipo de proceso puede serun proceso de mejora. 

Las clases de sistemas mostradas en la Figura 28.4 pueden solaparse. Por lo tanto, los sis- 
temas pequenos a los que se les aplica reingenieria se pueden desarrollar utilizando un pro- 
ceso metodologico. Los sistemas grandes siempre necesitan un proceso gestionado. Sin em- 
bargo, los mismos metodos de diseno no son recomendables para todo tipo de aplicaciones. 
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y los sistemas grandes constan de subsistemas de diferentes tipos. Por lo tanto, los sistemas 
grandes se desarrollan utilizando un proceso gestionado que no se basa en metodos de dise- 
no particulares. 

La clasificacion de procesos proporciona una base para seleccionar el proceso correcto a 
utilizar cuando se desarrolla un tipo de producto particular. Por ejemplo, supongamos que se 
requiere un programa para ayudar a la migracion de un tipo de computadora a otra. El tiem- 
po de vida de este programa sera relativamente corto. Su desarrollo no requiere los estanda- 
res, ni los procedimientos de gestion, que senan apropiados en el caso de que el sistema fue- 
se utilizado durante muchos anos. 

La clasificacion de procesos reconoce que el proceso afecta a la calidad del producto. Sin 
embargo, no supone que el proceso sea siempre el factor dominante. Provee una base parame- 
jorardiversos tipos de procesos. Se aplican diferentes tipos de mejora de procesos a diferen- 
tes tipos de procesos. Por ejemplo, las mejoras para los procesos metodologicos se basan en 
mejores metodos de capacitacion, mejor integracion de los requerimientos y el diseno, herra- 
mientas CASE mejoradas, etc. 

La mayoria de los procesos software tienen ahora el apoyo de herramientas CASE, por lo 
que son procesos con soporte. En la actualidad, los procesos metodologicos por lo general son 
apoyados porbancos de trabajo de analisis y diseno. Sin embargo, los procesos pueden tener 
otras clases de herramientas de apoyo (por ejemplo, herramientas para la creacion de proto- 
tipos, herramientas de pruebas) independientemente de que se utilice o no un metodo de di- 
seno estructurado. 

El apoyo de las herramientas que puede ser efectivo en el apoyo de los procesos depende 
de la clasificacion del proceso. Por ejemplo, los procesos informales pueden utilizar herra- 
mientas genericas, como los lenguajes para la construccion de prototipos, compiladores, de- 
puradores, procesadores de texto, etc. Sin embargo, raramente utilizan herramientas especia- 
lizadas de una forma consistente. La Figura 28.5 muestra diversas herramientas a utilizar en 
el desarrollo de software. La efectividad de las herramientas depende del tipo de procesos uti- 
lizados. 

Las herramientas CASE para analisis y diseno son las mas efectivas cuando se sigue un pro- 
ceso metodologico. Las herramientas especializadas dan soporte a actividades individuales. Por 
ejemplo, el equipo implicado en el desarrollo llevado a cabo desde diferentes localizaciones, 
puede crear una herramienta para mostrar como va el trabajo en cada sitio. A veces, estas he- 
rramientas especializadas deben ser desarrolladas especialmente para mejorar el proceso. 
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28.3 Medicion del proceso 

Las mediciones del proceso son datos cuantitativos de los procesos del software. Humphrey 
(Humphrey, 1989), en su libro sobre mejora de procesos, senala que la medicion de los atri- 
butos de proceso y de producto es esencial para la mejora de procesos. Tambien senala que las 
mediciones desempenan un papel importante en la mejora de procesos de personal a pequena 
escala (Humphrey, 1995). Las metricas de proceso se utilizan para evaluar si la eficiencia de 
un proceso ha mejorado. Por ejemplo, se puede medir el esfuerzo y tiempo dedicados a las 
pruebas. Las mejoras efectivas para los procesos de prueba reducen el esfuerzo, el tiempo de 
prueba o ambos. Sin embargo, las mediciones de procesos, por si mismas, no se pueden utili- 
zarpara determinar si la calidad del producto ha mejorado. Las metricas de producto (vease 
el Capltulo 27) tambien deben hacerse y relacionarse con las actividades del proceso. 
Se pueden recogertres clases de metricas de proceso: 

1 . El tiempo requerido para completar un proceso en particular. Es el tiempo total de- 
dicado al proceso, el tiempo de calendario, el tiempo invertido en el proceso por in- 
genieros particulares, etcetera. 

2. Los recursos requeridos para un proceso en particular. Los recursos pueden ser el es- 
fuerzo total en personas/dla, los costes de viajes, los recursos de computo, etcetera. 

3. El numero de ocurrencias de un eve lit <> en particular. Ejemplos de eventos que se 
pueden supervisar son: el numero de defectos descubiertos durante la inspeccion del 
codigo, el numero de peticiones de cambios en los requerimientos, el numero pro- 
medio de llneas de codigo modificadas en respuesta a un cambio de requerimientos, 
etcetera. 

Los dos primeros tipos de mediciones se utilizan para ayudar a descubrir si los cambios en 
el proceso mejoran la eficiencia de un proceso. Por ejemplo, supongamos que existen puntos 
fijos en un proceso de desarrollo de software como la aceptacion de requerimientos, la termi- 
nacion de un disefio arquitectonico, la terminacion de la generacion de datos de prueba, etce- 
tera. Es posible medir el tiempo y esfuerzo requeridos para moverse de uno de estos puntos fi- 
jos a otro. Los valores medidos se utilizan para indicar areas donde se puede mejorar el proceso. 
Despues de introducir los cambios, las mediciones de los atributos del sistema muestran si los 
cambios en el proceso han sido beneficiosos para reducir el tiempo o esfuerzo requerido. 

Las mediciones del numero de eventos que ocurren tienen una influencia directa en la ca- 
lidad del software. Por ejemplo, incrementar el numero de defectos descubiertos al cambiar 
el proceso de inspeccion del programa probablemente se reflejara en una mejora de la cali- 
dad del producto. Sin embargo, esto tiene que confirmarse por mediciones posteriores del pro- 
ducto. 
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La dificultad fundamental en la medicion del proceso es conocer que medir. Basili y Rom- 
bach (Basili y Rombach, 1988) propusieron el paradigma denominado G Q M (Goal-Question- 
Metric). Este se utiliza para ayudar a decidir que mediciones tomar y como utilizarlas. Este 
enfoque se basa en la identificacion de: 

1. Metas. Lo que la organizacion esta tratando de lograr. Ejemplos de metas son mejorar 
la productividad de los programadores, reducir los tiempos de desarrollo del produc- 
to, incrementar la fiabilidad del producto, etcetera. 

2. Preguntas. Son refinamientos de las metas en las que se identifican las areas especifi- 
cas de incertidumbre relacionadas con las metas. Normalmente, una meta tendra va- 
rias preguntas asociadas que requieren respuesta. Ejemplos de preguntas relacionadas 
con las metas anteriores son: 

• i,C6mo se puede incrementar el numero de lineas de codigo depuradas? 

• ;,C6mo se puede reducir el tiempo necesario para finalizar los requerimientos del 
producto? 

• i,C6mo se puede llevar a cabo de forma mas efectiva las evaluaciones de la fiabili- 
dad? 

3. Metricas. Son mediciones que hay que recoger para ayudar a responder las preguntas 
y confirmar si las mejoras del proceso ayudaron a cumplir la meta deseada. En los 
ejemplos anteriores, las mediciones que se podrian hacer son medir la productividad 
de los programadores individuals en lineas de codigo y su nivel de experiencia, me- 
dir el numero de comunicaciones formales entre el cliente y el proveedor para cada 
cambio de los requerimientos y medir el numero de pruebas requeridas para provocar 
una caida en el producto. 

La ventaja de este enfoque cuando se aplica a la mejora de procesos es que separa las 
cuestiones organizadonales (las metas) de las cuestiones especificas del proceso (las pre- 
guntas). Se centra en la recoleccion de datos y senala que estos datos se deben analizar de 
diferentes formas, dependiendo de la pregunta que se pretenda contestar. Basili y Green (Ba- 
sili y Green, 1993) describen como se utilizo este enfoque en un programa a largo plazo de 
mejora de procesos basado en las mediciones. 

En el metodo ami de mejora de procesos del software (Pulford eta/., 1996), el enfoque 
GQ Mse desarrollo ycombino con el modelo demadurez de lacapacidaddel SEI. Losdesa- 
rrolladores del metodo ami proponen un enfoque de etapas para la mejora de procesos en la 
que las mediciones se incluyen despues de que la organizacion haya introducido algiin tipo 
de disciplina en sus procesos. Esto proporciona guias y consejos practicos al implementar la 
mejora de procesos basada en mediciones. 

28.4 Analisis y modelado de procesos 

El analisis y modelado de procesos comprende estudiar los procesos existentes y desarrollar 
un modelo abstracto de estos procesos que capte sus caracteristicas principales. Estos mode- 
los ayudaran a comprender el proceso y a comunicarlo a otros. A lo largo del libro, se han uti- 
lizado fragmentos de modelos de procesos para analizar actividades especificas como la in- 
genieria de requerimientos, el diseno de software, etcetera. Como se expuso en la Figura 28.2, 
el proceso de analisis sigue al proceso de medicion. Esta es una simplificacion porque, en re- 
alidad, estan entrelazadas. Se debe llevar a cabo un analisis previo para saber lo que se quie- 
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re medir y, cuando se hagan las mediciones, forzosamente se desarrollara una mejor com- 
prension del proceso de medicion. 

El analisis de procesos estudia los procesos existentes para comprender las relaciones en- 
tre las diferentes partes del proceso. Las etapas iniciales del analisis de procesos son inevita- 
blemente cualitativas: el analista simplemente trata de descubrir las caracteristicas principa- 
les del modelo. Las etapas posteriores son mas cuantitativas y se utilizan diversas metricas de 
proceso. Despues del analisis, los procesos se describen utilizando un modelo de procesos 
(Huff, 1996). 

El punto inicial del analisis de procesos debe ser cualquiera de los modelos de procesos 
«formales» . Muchas organizaciones cuentan con un modelo formal impuesto por el cliente del 
software. Este estandar define las actividades criticas y el ciclo de vida de los productos a en- 
tregar que se deben producir. 

Los modelos formales sirven como un punto de inicio util para el analisis de procesos. Sin 
embargo, raramente incluyen suficiente detalle o reflejan las actividades reales del desarrollo 
de software. Los modelos de procesos formales son mas abstractos y solo definen las activi- 
dades y productos a entregar del proceso principal. Por lo general, es necesario mirar «hacia 
adentro» del modelo para descubrir los procesos reales. Mas aun, los procesos reales que se 
siguen a menudo difieren significativamente de los modelos formales, aunque por lo general 
se tengan que desarrollar los productos a entregar. 

Las tecnicas de analisis de procesos comprenden: 

1 . Cuestionarios y entrevistas. A los ingenieros que trabajan en un proyecto se les pre- 
gunta sobre lo que sucede realmente. Las respuestas a un cuestionario formal se refi- 
nan durante las entrevistas personales con los involucrados en el proceso. 

2. Estudios etnogrdflcos. Como se comento en el Capitulo 7, los estudios etnograficos se 
utilizan para comprender la naturaleza del desarrollo de software como una actividad 
humana. Tal analisis revela la sutileza y complejidades no descubiertas porotras tec- 
nicas. 

Cada uno de estos enfoques tiene ventajas y desventajas. El analisis basado en cuestio- 
narios se lleva acabo rapidamente una vez que se han disefiado las preguntas correctas. Sin 
embargo, si las preguntas no estan bien redactadas o son inapropiadas. esto conducira a un 
modelo incompleto o impreciso del proceso, Mas aun, el analisis basado en cuestionarios 
es parecido a un formulario de evaluacion. Los ingenieros encuestados dan las respuestas 
que creen que el encuestador desea escuchar en lugar de la verdad acerca del proceso utili- 
zado. 

Las entrevistas con la gente involucrada en el proceso son mas flexibles que los cuestio- 
narios. Se puede empezar con un guion de preguntas previamente preparado, pero adaptando 
estas a las respuestas que se espera obtener de las diferentes personas. Si se da la oportunidad 
a los participantes de dialogar mas ampliamente, se puede observar que estos hablan acerca 
de los problemas del proceso, los cambios que esta experimentando el proceso, etc. 

El analisis etnografico es mas apropiado para descubrir los procesos que realmente se uti- 
lizan. Sin embargo, es una actividad costosa y a largo plazo que puede durar por lo menos va- 
rios meses. Se basa en la observacion externa del proceso. Un analisis completo debe conti- 
nuar desde las primeras etapas del proyecto hasta la entrega y mantenimiento del producto. 
Probablemente esto no es practico en proyectos largos que duran varios afios. El analisis et- 
nografico, por lo tanto, es mas util cuando se requiere un conocimiento profundo de los frag- 
mentos del proceso. Deben llevarse a cabo estudios a pequefia escala centrandose en los de- 
talles de proceso. 
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Los modelos de proceso son vistas simplificadas de los procesos de software, donde se 
muestran las actividades y las salidas del proceso. Los modelos de proceso utilizados en este 
libro son modelos abstractos simplificados que presentan una vision genericade los procesos 
en cuestion. En este nivel abstracto, estos procesos son los mismos en muchas organizacio- 
nes. Sin embargo, estos modelos genericos tienen diferentes instancias, dependiendo del tipo 
de software a desarrollar y del entorno organizacional. Los modelos detallados de procesos 
por lo general no son transferibles de una organizacion a otra. 

Los modelos de procesos genericos son una base util para analizar los procesos. Sin em- 
bargo, no incluyen suficiente informacion para el analisis y mejora de procesos. Esta requie- 
re informacion de las actividades, los productos a entregar, las personas, las comunicaciones, 
la duracion y otros procesos organizacionales que afectan al proceso de desarrollo. La Figu- 
ra 28.6 explica lo que se podria incluir en un modelo de procesos detallado. 

En un modelo de procesos tambien se registra el tiempo y las dependencias entre las acti- 
vidades, los productos a entregar y las comunicaciones. A veces las actividades se llevan a 
cabo en paralelo y a veces en secuencia. Estan entrelazadas de tal forma que el mismo inge- 
niero esta involucrado en varias actividades. Los productos a entregar dependen de otros pro- 
ductos o de algunas comunicaciones entre los ingenieros que trabajan en el proceso. 

En los ejemplos de los modelos de procesos del libro, se muestra la secuencia aproxima- 
da de actividades de izquierda a derecha. Las actividades que se llevan a cabo en paralelo se 
dibujan verticalmente, en la medida de lo posible. 





Acthridad (representada por un 
rectanguio redondeado sin sombra) 


Una acthridad bene daramente definidos un objetivo, las entradas y las condictones 
de salkla. Ejemplos de actividades son preparer un conjunto de datos de prueba para 
probar un modulo, codifkar una funtibn o m6dulo, hacer la prueba de lectura a un 
documento, etcetera. Por lo general, una actividad es atdmica, es dear, incumbe a 
una persona o a un grupo. No se descompone en subactividades. 


Proceso (representado por un 
rectanguio redondeado con sombra) 


Un proceso es un conjunto de actividades que tiene alguna coherencia , cuyo obje- 
tivo, por lo general, se acuerda dentro de la organization. Ejemplos de procesos son 
el anilisis de requerimientos, el disefto arquitectdnico, la planificacion de pruebas, 
etoetera. 


Producto a entregar (representado 
por un rectanguio con sombra) 


Un producto a entregar es una salida tangible de una acthridad prevista en un plan 
de proyecto. 


Condicidn (representada 
por un paralelogramo) 


Una condition es o una precondition que debe cumplirse antes de inkiar un pro- 
ceso o actnridad o una postcondition que se dimple despues de terminer el proce- 
so o la acthridad. 


Rol (representado por un 
cfrculo con sombra) 


Un rol es un irea limhada de responsabilidad. Ejemplo de roles son el gestor de con- 
figuraciones, el ingeniero de pruebas, el diseAador de software, etc Una persona 
puede tener varios roles distintos, y un solo rol se puede asotiar a varias personas. 


Exception (no se muestra en los 
ejemplos pero se representa como un 
cuadro de doble borde) 


Una exception es una description de c6mo modtficar el proceso si ocurre un even- 
to antidpado o no anticipado. Las excepciones a menudo son indefinidas y se deja 
a la habilidad de los administradores e ingenieros del proyecto el manejo de la ex- 
ception. 


Comunicacion (representada 
por una flecha) 


Un intercambio de information entre personas o entre personas y ststernas de com- 
pute de apoyo. Las comunicaciones pueden ser informales o formates. Las comuni- 
caciones forma les podrfan ser que un administrador del proyecto apruebe un pro- 
ducto a entregar; las comunicaciones informales podrian ser el intercambio de un 
correo electronico para resolver las ambigOedades en un documento. 



HgUra 28.6 Elementos de un modelo de proceso. 



28.4 • Analisis y modelado de procesos 



617 



Precondition 



El m6dulo 
compila sin erroresj 
de sintaxis 



Figura 28.7 
El proceso 
de pruebas 
de un modulo. 



Entrada 



Especificacion 
del m6dulo 



Responsable 
de 




Proceso 



Postcondition 



/ Todas las pruebas 
I definidas se ejecutanj 
en el m6dulo g 



Salidas 





Registro de 


5 


pruebas firmado 



Datos de prueba 
del modulo 



Los modelos de procesos detallados son sumamente complejos. Por ejemplo, consideremos 
los fragmentos de proceso mostrados en las Figuras 28.7 y 28.8. Estos describen el proceso 
de probar un modulo de un sistema grande que utiliza un proceso de gestion de configuracio- 
nes controlado de forma estricta {vease el Capitulo 29). El software a probar y los datos de 
pruebas estan bajo el control de la configuracion. La Figura 28.7 muestra el rol responsable 
del proceso de prueba, las entradas y salidas del proceso y las pre y postcondiciones. 

La Figura 28.8 descompone el proceso «Probarm6dulo» en varias actividades separadas. 
Este fragmento muestra solo las actividades relativamente simples de la prueba del modulo. 
Existen cuatro series de actividades: preparar los datos de prueba, redactarun codigo de prue- 
bas para un modulo, ejecutar las pruebas y hacer informes de pruebas. Las actividades en la 
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Figura 28.8 Las actividades involucradas en la prueba de un modulo. 
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serie de preparacion normalmente estan entrelazadas. Obviamente, las actividades de prepa- 
racion preceden a laejecucion y elaboracion del informe de actividades. 

En este diagrama se ha dejado informacion sobre las pre y postcondiciones del proceso y 
sobre las entradas y salidas del proceso. Esta informacion haria que el modelo fuera comple- 
jo y dificil de comprender. En lugar de tratar de tener toda la informacion en un solo modelo, 
se necesita hacer varios modelos en diferentes niveles de abstraccion. Estos se relacionan por 
medio de los elementos comunes como las actividades y los productos a entregar. Algunos 
modelos se refierenprimordialmente a las actividades del proceso; otros, a la informacion de 
control que dirige la ejecucion del proceso. 

28.4.1 Excepclones del proceso 

Los procesos del software son entidades muy complejas. Aunque exista un modelo de procesos 
definido en una organizacion, este solo representa la situacion ideal en la que el equipo de desa- 
rrollo se enfrenta con problemas no previstos. En la realidad, los problemas no previstos son un 
hecho de la vida diaria para los gestores del proyecto. El modelo de procesos «ideal» debe mo- 
dificarse dinamicamente puesto que se deben encontrar soluciones a esos problemas. Ejemplos 
de estos tipos de excepciones a las que se enfrenta un administrador de proyectos son: 

1. Varias personas clave enferman al mismo tiempo, justo antes de revisar un proyecto. 

2. Una averia en la computadora de seguridad que deja todas las comunicaciones fuera 
de servicio durante varias horas. 

3. Se lleva a cabo una reorganizacion de la organizacion, lo que significa que los gesto- 
res tienen que invertir gran parte de su tiempo trabajando en cuestiones organizacio- 
nales en lugar de la gestion del proyecto. 

4. Se hace una peticion no prevista de propuestas para nuevos proyectos. El esfuerzo se 
transfiere de un proyecto a trabajar en una propuesta. 

En general, el efecto de un imprevisto es que, de alguna forma, los recursos, los presu- 
puestos o los tiempos de un proyecto cambian. Es dificil predecir todos los imprevistos e in- 
corporarlos en un modelo de proceso formal. Se tendran que manejardinamicamente estos im- 
previstos cambiando el proceso «estandar» para enfrentarse a estas circunstancias inesperadas. 
Por lo tanto, los modelos de proceso son inevitablemente incompletos, y el gestor del proyecto 
es responsable de tratar estos imprevistos y de adaptar el proceso como se requiera. 



28.5 Cambio en los procesos 

El cambio en el proceso significa hacer modificaciones en el proceso existente. Se puede ha- 
cer introduciendo nuevas practicas, metodos o herramientas, cambiando el orden de las acti- 
vidades, introduciendo o eliminando entregas del proceso, o introduciendo nuevos roles y res- 
ponsabilidades. Deben fijarse metas para la mejora del proceso, como «reducir en un 25% el 
numero de defectos descubiertos durante la prueba de integracion». Estas metas deben con- 
ducir el cambio en el proceso y, una vez realizados cambios, deben utilizarse para evaluar el 
progreso. 

Existen cinco etapas clave en el proceso de «cambio de procesos» (Figura 28.9): 

1. Identification de la mejora. Esta etapa comprende utilizar los resultados del analisis 
del proceso para identificar la calidad, la duracion o los cuellos de botella de los eos- 
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tes donde los factores del proceso influyen de forma adversa en la calidad de produc- 
to. La mejora de procesos se centra en desvelar estos cuellos de botella proponiendo 
nuevos procedimientos, metodos y herramientas para abordar los problemas. 

2 . Priorizacion de la mejora. Esta etapa se centra en la evaluacion de los cambios y en 
establecimiento de las prioridades para su implementacion. Cuando se identifican mu- 
chos cambios posibles, normalmente es imposible introducirlos todos al mismo tiem- 
po. Se tendra que decidir cuales son los mas importantes. Pueden basarse las decisio- 
nes en las necesidades de mejora en areas especlficas del proceso, los costes de 
introducir los cambios, el impacto del cambio en la organizacion entre otros factores. 

3. Introduction del cambio delproceso. La introduccion del cambio del proceso signifi- 
ca agregar nuevos procedimientos, metodos y herramientas e integrarlas con otras ac- 
tividades del proceso. Es importante dejar suficiente tiempo para introducir los cam- 
bios y asegurar que estos son compatibles con otras actividades del proceso y con los 
procedimientos y estandares organizacionales. 

4. Capacitacion en el cambio delproceso. Sin capacitacion, no es posibleobtener los be- 
neficios totales de los cambios del proceso. Pueden ser rechazados por los gestores y 
los ingenieros responsables de los proyectos de desarrollo. De igual forma, imponer 
los cambios del proceso sin la capacitacion adecuada conduce a que estos cambios 
sean para degradar en lugar de mejorar la calidad del producto. 

5. Refinamiento del cambio. Los cambios del proceso propuestos no son efectivos com- 
pletamente al momento de introducirlos. Es necesario que exista una fase de ajuste 
donde se descubren problemas menores y se proponen e introducen las modificacio- 
nes al proceso. Esta fase de refinamiento dura varios meses hasta que los ingenieros 
de desarrollo estan contentos con el nuevo proceso. 

Una vez que se introduce un cambio, el proceso de mejora se itera con analisis adiciona- 
les para identificar problemas en el proceso, proponer mejoras, etcetera. No es practico in- 
troducir muchos cambios al mismo tiempo. Aparte de los problemas de capacitacion que esto 
provoca, introducir muchos cambios hace imposible evaluar el efecto de cada cambio en el 
proceso. 

El gestor debe ser sensible a los sentimientos de la gente de su equipo cuando introduce 
cambios en el proceso. El proceso de reingenieria en los negocios (Hammer, 1990; Ould, 
1995), de moda en los anos 90, conllevo cambios radicales en los procesos, pero no fue sa- 
tisfactorio en muchos casos debido a que no se tuvo en cuenta a las personas involucradas. 
Estas sintieron que su experiencia fue soslayada y que sus puestos de trabajo cambiaron sin 
ningun tipo de consulta. Se resistieron a los cambios y aseguraron que con estos cambios no 
trabajarian. 

No hay duda de que algunas personas se sienten amenazadas por el cambio o preocupadas 
por perder su trabajo o ser incapaces de adaptarse a las nuevas formas de trabajar. El gestor 
tiene que involucrar a todo el equipo en el proceso de cambio, entendiendo sus dudas e im- 
plicandolos en la planificacion del proceso nuevo. Interesandolos en el proceso de cambio, 
sera mas facil que ellos deseen hacerlo. 

28.6 El marco de trabajo para la mejora de procesos CMMI 

El software Engineering Institute (SEI) se establecio para mejorar las capacidades de la in- 
dustria de software de los Estados Unidos de America. A mediados de los 80, el SEI inicio 



620 



C A P ITU LO 26 • Mejora de procesos 



un estudio de las formas de evaluar las capacidades de los proveedores de software. El resul- 
tado de estos estudios fue el Modelo de Madurez de laCapacidad de Software del SEI (CMM) 
(Paulk et al., 1993; Paulk et ah, 1995). Ha influido tremendamente en el convencimiento de 
la comunidad de ingenierla del software, para considerar seriamente la mejora de procesos. 
Al modelo C M M de software lo siguieron otros modelos de capacidad de madurez, entre ellos 
el Modelo de Madurez de laCapacidad de Personal (P-CMM) (Curtis etal, 2001), expuesto 
en el Capitulo 25. 

Otras organizaciones han desarrollado modelos de madurez del proceso similares. El mo- 
delo SPICE que aproxima a la valoracion de la capacidad y a la mejora del proceso (Paulk y 
Konrad, 1994) es mas flexible que el modelo del SEL Incluye niveles de madurez similares a 
los niveles del SEI, pero ademas identifica procesos, como los procesos entre cliente y pro- 
veedor, que recorren estos niveles. A medida que subimos en nivel de madurez, el rendimiento 
de estos procesos clave debe mejorarse. 

El proyecto Bootstrap tenia el objetivo de extender adaptar el modelo de madurez del 
SEI parahacerlo aplicable aun amplio espectro de companias. El modelo Bootstrap (Haa- 
se et al., 1994; Kuvaja et al., 1994) utiliza los niveles de madurez del SEI, pero ademas 
incorpora: 

1 . Guias de calidad para ayudar en la mejora de procesos de las companias. 

2. Una distincion importante entre organizacion, metodologia y tecnologia. 

3. Un modelo de proceso base (basado en el modelo utilizado por la Agencia Espacial 
Europea) que podria adoptarse. 

En un intento de integrar la amalgama de modelos que se habian desarrollado (incluyen- 
do sus propios modelos), el SEI se embarco en un nuevo programa para desarrollar un mo- 
delo de capacidad integrado (CMMI). Este sustituye al software y a los sistemas de ingenie- 
ria basados en C M M e integra a otros modelos de ingenieria. Tiene dos instancias, en etapas 
y continuo, y (rata algunas de las debilidades del C M M de software. 

El modelo CMMI (Ahem et al., 2001) intenta ser un marco de trabajo para la mejora del 
proceso que sea aplicable en un amplio abanico de companias. Su version en etapas es com- 
patible con el C M Mde software ypermiteundesarrollo delsistemade la organizacion, lages- 
tion de los procesos a valorar y su asignacion a un nivel de madurez entre 1 y 5. Su version 
continua permite una clasificacion mas detallada y considera 24 areas de procesos (vease la 
Figura 28.10) en una escala de 1 a 6. 

El modelo es muy complejo (su descripcion tiene mas de 1.000 paginas), por lo que he- 
mos tenido que simplificarlo: 

1. Areas deproceso. El CMMI identifica 24 areas de procesos que son relevantes para la 
capacidad y la mejora del proceso software. Estas estan organizadas en cuatro grupos 
en el modelo CMMI continuo. En la Figura 28.10 podemos ver estos grupos y sus co- 
rrespondientes areas. 

2. Metas. Las metas son descripciones abstractas de un estado deseable que deberia ser 
alcanzado por una organizacion. El CMMI tiene metas especificas asociadas a cada 
area de procesos y que definen el estado deseable para esta area. Tambien tiene metas 
genericas que son asociadas con la institucionalizacion de buenas practicas. La Figu- 
ra 28.11 muestra algunas metas especificas y genericas en el CMMI. 

3. Practicas. Las practicas en el CMMI son descripciones de vias para conseguir una 
meta. Se pueden asociar hasta siete practicas especificas o genericas con cada meta 
dentro de cada area de procesos. La Figura 28.12 muestra ejemplos de practicas re- 
comendadas. Sin embargo, el CMMI reconoce que lo importante es la meta, no el 
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Figura 28.10 

Areas de proceso 
en el CMMI. 



Definition de procesos organiiacionales 
Centrar la atencidn en procesos organizational 
Aprendizaje organizational 
Rendimiento de los procesos organizacio males 
Desarrollo e innovation organizational 



Planfficacion del proyecto 
Control y seguimiento del proyecto 
Gestibn de acuerdos con los proveedores 
Gestion de la irrtegracidn del proyecto 
Gesti6n de riesgos 
Integration de! equipo 
Gestion cuantftativa del proyecto 



Gesti6n de requerimientos 
Desarrollo de requerimientos 
Soluciones tecnicas 
Integration del producto 
Verification 
Validati6n 
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Gestion de calidad del proceso y del producto 

Analisis y medkiones 

Analisis y toma de detisiones 

Entomo organizacional para integrati6n 

Analisis y resolution causal 



camino que lleva a ella. Las organizaciones utilizan cualquier practica apropiada 
para alcanzar cualquier meta del C M M I ; no tienen por que seguir las recomenda- 
ciones del CMMI . 

Las metas y practicas genericas no son tecnicas, pero estan asociadas con la instituciona- 
lizacion de las buenas practicas, lo que significa que dependen de la madurez de la organiza- 
cion. Por lo tanto, en una organizacion nueva que se halla en una etapa temprana del desarrollo 
de la madurez, la institucionalizacion puede significar el seguimiento de los planes y los pro- 
cesos establecidos. Sin embargo, en una organizacion con mas madurez, procesos avanzados, 
ta institucionalizacion puede significar controlar los procesos utilizando tecnicas estadisticas 
u otras tecnicas cuantitativas. 



Figura 28.11 
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Figura 28.12 
Practicas y metas 
asociadas en el 
CMMI. 
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La valoracion de un CMMI implica examinar los procesos en una organizacion y clasi- 
ficarlos en una escala de seis puntos que reflejan el nivel de madurez en cada area de pro- 
ceso. A un proceso se le asigna el nivel en la escala de seis puntos como sigue: 

1. No productlvo. No se satisfacen una o mas de las metas especlficas asociadas con el 
area de proceso. 

2. Productivo. Se satisfacen las metas asociadas al area de proceso, y para todos los 
procesos el ambito del trabajo a realizar es fijado y comunicado a los miembros del 
equipo. 

3. Gestionado. A este nivel, las metas asociadas con el area de proceso son conocidas y 
tienen lugar politicas organizacionales que definen cuando se debe utilizar cada pro- 
ceso. Debe haber planes documentados, gestion de recursos y monitorizacion de pro- 
cedimientos a traves de la institucion. 

4. Deflnldo. Este nivel se centra en la estandarizacion organizacional y el desarro- 
llo de procesos. Cada proyecto de la organizacion tiene un proceso de gestion 
creado a medida desde un conjunto de procesos organizacionales. La informacion 
y las medidas del proceso son recogidas y utilizadas para las mejoras futuras del 
proceso. 

5. Gestionado cuantitativamente. En este nivel, existe una responsabilidad organizacio- 
nal de usar metodos estadisticos y otros metodos cuantitativos para controlar los sub- 
procesos. Esto significaque en el proceso de gestion debemos utilizar medidas del pro- 
ceso y del producto. 

6 Optimizado. En este nivel superior, la organizacion debe utilizar medidas de proceso y 
de producto para dirigir el proceso de mejora. Debemos analizar las tendencias y adap- 
tar los procesos a las necesidades de los cambios del negocio. 

Por supuesto, esto es una descripcion simplificada de los niveles de capacidad, pero se pue- 
de pensaren estos niveles como algo progresivo, con una descripcion explicita de los proce- 
sos en los niveles mas bajos, y donde las mediciones de proceso y producto dirigiran la es- 
tandarizacion del proceso para cambiarlo y mejorarlo. 
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28.6.1 □ modelo CMMI en etapas 

El modelo C M M I de niveles es comparable con el modelo C M M de software en el sentido en 
que provee una forma de valorar la capacidad del proceso de una organizacion clasificando- 
la en uno de cinco niveles. El modelo describe las metas que se deben alcanzar en cada uno 
de estos niveles. La mejora de procesos se lleva a cabo implementando practicas en cada ni- 
vel, subiendo desde el nivel inferior hasta el superior del modelo. LaFigura 28.13 muestra los 
cinco niveles de este modelo CMMI. 

Cada nivel de madurez tiene asociado un conjunto de areas de proceso y metas genericas. 
Por ejemplo, las areas de proceso definidas para el segundo nivel del modelo (nivel gestiona- 
do) son: 

1. Gestion de requerimientos. Gestiona los requerimientos del proyecto y de sus com- 
ponentes, e identifica inconsistencias entre estos requerimientos y el plan y los pro- 
ductos del proyecto. 

2. Planificacion del proyecto. Establece y mantiene los planes, los cuales definen las ac- 
tividades del proyecto. 

3. Seguimiento y control del proyecto. Provee la comprension del progreso del proyecto 
y la aplicacion de medidas correctivas cuando el rendimiento del proyecto se desvia 
significativamente del plan. 

4. Acuerdos con los proveedores. Gestiona la adquisicion de productos yservicios de 
proveedores extemos al proyecto con los cuales existen acuerdos formales. 

5 . Andlisisy mediciones. Desarrolla y mantiene una capacidad de medicion que se utili- 
za en el soporte de gestion de la informacion. 

6. Garantia de la calidad del proceso y del producto. Provee personal y gestion con com- 
prension objetiva del proceso y los productos de trabajo asociados. 

7. Gestion de conflguraciones. Establece y mantiene la integridad de los productos de tra- 
bajo usando identificacion, control y estado de conflguraciones, asi como auditorias. 

Asi como estas practicas especificas, la operativa de las organizaciones en el segundo 
nivel en el modelo CMMI debe haber alcanzado metas genericas de institucionalizacion 
donde cada uno de los procesos sea un proceso gestionado. Ejemplos de practicas institu- 
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cionales asociadas con la planificacion del proyecto que permiten a este proceso ser un 
proceso gestionado son: 

• Establecer y mantener una politica organizacional de planificacion y mejora del proce- 
so de planificacion. 

• Proveer los recursos adecuados para mejorar el proceso de gestion del proyecto, des- 
arrollando las herramientas y proveyendo los servicios al proceso. 

• Seguimiento y control del proyecto y aplicacion de las medidas correctivas adecuadas 
cuando sea necesario. 

• Revision de actividades, estado y resultados del proceso de planificacion del proyecto 
con una gestion a alto nivel y resolucion de problemas. 

La ventaja del modelo CM MI en etapas, aparte de su compatibilidad con el modelo C M M , 
es que define un camino claro para la mejora de las organizaciones. Estas subiran del segun- 
do al tercer nivel, y asi sucesivamente. La desventaja es que podria ser mas adecuado intro- 
ducir metas y practicas correspondientes a los niveles superiores antes que las practicas de ni- 
veles inferiores. Cuando una organizacion hace esto, la valoracion de su madurez da una 
imagen enganosa. 



28.6.2 El modelo CMMI contlnuo 

Los modelos de madurez continuos no clasifican a las organizaciones en niveles discretos. Estos 
son modelos que hilan mas fino y que consideran practicas individuales, grupos de estas y sus 
valoraciones. La valoracion de la madurez no es, por lo tanto, un solo valor, sino un conjunto de 
valores que muestran la madurez de la organizacion para cada proceso o grupo de procesos. 

El modelo CMMI continuo evalua cada area de proceso (vease la Figura 28.10) y le asig- 
na una nivel de valoracion entre 1 y 6 (como ya describimos) a cada area de proceso. 

Normalmente, las organizaciones operan a diferentes niveles de madurez en distintas areas 
de proceso. En consecuencia, el resultado de una valoracion con el modelo CMMI continuo 
es un perfil de capacidad que muestra cada area de proceso y su correspondiente valoracion 
de capacidad. La Figura 28.14 muestra un fragmento de un perfil de capacidad donde pode- 
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mos ver diferentes procesos con diferentes niveles de capacidad. Las organizaciones pueden 
desarrollar perfiles de capacidad actuales o futuros, donde estos perfiles futuros reflejarian el 
nivel de capacidad en cada area de proceso que se espera alcanzar. 

La principal ventaja del modelo continuo es que las organizaciones pueden elegir proce- 
sos de mejora de acuerdo con sus propias necesidades y requerimientos. La experiencia de- 
muestra que diferentes tipos de organizaciones tienen distintos requerimientos en su mejora 
de procesos. Por ejemplo, una empresa que desarrolla software para la industria aeroespacial 
puede centrarse en mejoras de la especificacion del sistema, gestion de configuraciones y va- 
lidacion, mientras que una empresa de desarrollo Web estaria mas interesa en los procesos 
cara al cliente. El modelo de niveles requiere que las companias se centren en los diferentes 
niveles sucesivamente. Sin embargo, el modelo CM MI continuo permite mas flexibilidad 
manteniendo la ayuda del CMMI. 



PUNTOS CLAVE 

• La mejora de procesos comp re nde el anal Isdel proceso, laestandarizaci6n,lamedicionyelcambio.Elapren- 
dizaje es esencial si la mejora de proceso va a llevarse a cabo. 

• Los procesos pueden clasificarse como informales, gestionados, metodologicos y de mejora. Podemos utlll- 
zar esta clasificacion para Identificar las herramientas de soporte al proceso. 

• El ciclo de mejora del proceso comprende medicion, analisis del proceso y cambio del modeladoydel proceso. 

• Lamedicidndebeserusadapara respond era preguntas especificasdel proceso software utilizado.Estascues- 
tiones deben basarse en metas de mejora organizaclonales. 

• Se pueden usar tres metricasdeproceso:metricasdetiempo,deutilizaci6nde recursos y de eventos. 

• Los modelos de proceso incluyen descripciones de actividades» subprocesos, roles, excepciones, comunica- 
ciones, entregas y otros procesos. 

• El modelo de madurez de proceso CMMI es un modelo de mejora de procesos integrado que soporta la mejo- 
ra de procesos en etapas y continuo. 

• En el modelo CMMI, la mejora de procesos esta basada en alcanzar un conjunto de metas relacionadas con 
tas buenas practicasde Ingenlerfa del software ydescribir, analizarycontrolar las practicasutilizadas para a I - 
canzar estas metas. El modelo CMMI incluye practicas recomendadas que pueden utilizarse, pero no obliga a 
utilizarlas. 



LECTURAS ADICIONALES 



CMMI Distilled. En el momento de escritura de este libro, el unico resumen conciso sobre el modelo CMMI. Es facil 
de leersi ya se comprende el modelo CMM, ya que le falta una introduction general a la mejora de procesos. (D. M. 
Ahern et al., 2001, Addison-Wesley.) 
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«Can you trust software capability evaluations". Este articulo hace una mirada esceptica al tema de ta evaluacidn 
de la capacidad y expone por que estas evaluaciones no dan una vision real de la madurez de la organizacidn. [E. 0'- 
Connell y Saiedian, IEEE Computer, 32(2), febrero de 2000.] 

Trenas in Software: Software Process Modelling and Technology. Este libro contiene una buena seleccidn de articu- 
los que tratan los diferentes aspectos de procesos software, incluyendo procesos de modelado, procesos de soporte 
y el uso del CMM. (A. Fuggetta y A. Wolf (eds.), 1996, John Wiley & Sons.) 

Managing the Software Process. Un texto clasico sobre mejora de procesos software y el primero que publico la no- 
cidndeaproximacidn estructurada a la mejora de procesos. A pesar de que el libro ya tiene bastantes alios, los con- 
sejos que contiene siguen siendo muy relevantes, especialmente en proyectos software grandes. (W. S. Humphrey, 
1988, Addison-Wesley.) 



EJERCICIOS 



28.1 Sugiera modelos de proceso para las siguientes acciones: 

• Encender una fogata de leha 

• Cocinar una comida de tres platos (los cuales se eligen en un menu) 

• Escribir un programa pequeno (50 lineas) 

2&2 £En que circunstancias se determina la calidad del producto a partir de la calidad del equipo de desarro- 
llo? De ejemplos de los tipos de productos de software que dependen particularmente del talento y la ha- 
bilidad individual. 

283 Explique por que un proceso metodoldgico no es necesariamente un proceso gestionado, como se define 
en la Seccidn 28.2. 

28.4 Sugiera tres herramientas software especializadas que puedan desarrollarse para dar suporte al progra- 
ma de mejora de procesos de una organizacidn. 

285 Suponga que la meta de la mejora de procesos en una organizacidn es incrementar el numero de compo- 
nentes reutilizables que se producen durante el desarrollo. Sugiera tres cuestiones en el paradigma GQM 
que conduzcan a esto. 

28.6 Describa tres tipos de metricas de proceso software que puedan ser parte de un proceso de mejora de pro- 
cesos. De un ejemplo de cada tipo de metrica. 

28.7 Disehe un proceso para valorar y priorizar propuestas de cambio en el proceso. Documente este proceso 
como un modelo de proceso que muestra los roles que intervienen en el. 

28.8 Senale dos ventajas y dos desventajas del enfoque de la valoracidn y la mejora del proceso incorporada 
en los marcos de trabajo de mejora de procesos como CMMI. 

28.9 j,En que circunstancias deberia recomendar el uso de la representacidn por niveles del CMMI? 

28.10 iQue diferencias hay entre metas genericas y especificas en el CMMI? 

28.11 ^Cuales son la ventajas y desventajas del uso modelos de madurez basados en metas frente a los basa- 
dos en practicas? 

28.12 e,Son intrinsecamente deshumanizados los programas de mejora de procesos que implican medir el tra- 
bajo de las personas en el proceso y que cambian dicho proceso? iQue resistencia puede surgir en un pro- 
grama de mejora de procesos? 
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de configuraciones 



Objetivos 

El objetivo de este capitulo es introducir el proceso de gestion del 
codigo y la documentacion de un sistema de software evolutive 
Cuando termine de leer este capitulo: 

• comprenderaporque es importante la gestion de la 
configuracion del software; 

• habra sido introducido en cuatro actividades principales de la 
gestion de configuraciones: planificacion de la gestion de 
configuraciones, gestion de los cambios, gestion de versiones y 
entregas, y construccion de sistemas; 

• aprendera como se pueden utilizar las herramientas CASE para 
apoyar los procesos de gestion de configuraciones. 

Contenidos 

29.1 Planificacion de la gestion de configuraciones 

29.2 Gestion del cambio 

29.3 Gestion de versiones y entregas 

29.4 Construccion del sistema 

29.5 Herramientas CASE para la gestion de configuraciones 
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La gestion de configuraciones (CM) es el desarrollo y aplicacion de estandares y procedi- 
mientos para gestionar un sistema software evolutivo. Como se expuso en el Capitulo 7, los 
requerimientos del sistema siempre cambian durante su desarrollo y su uso, y se tienen que 
incorporar estos requerimientos en nuevas versiones del sistema. Es necesario gestionar estos 
sistemas que evolucionan, porque es facil perder la pista de los cambios que se han incorpo- 
rado dentro de cada version. Las versiones incorporan propuestas de cambios, correcciones 
de fallos y, adaptaciones para hardware y sistemas operativos diferentes. Pueden existir va- 
rias versiones en desarrollo y en uso al mismo tiempo. Si no se tienen unos procedimientos 
de gestion de configuraciones adecuados, se puede hacer un esfuerzo inutil modificando la 
version erronea de un sistema, entregar una version incorrecta a los clientes o perder la pista 
de donde ha sido guardado el codigo fuente. 

Los procedimientos de gestion de configuraciones definen como registrar y procesar los 
cambios propuestos al sistema, como relacionar estos con los componentes del sistema y los 
metodos utilizados para identificar las diversas versiones del sistema. Las herramientas de 
gestion de configuraciones se utilizan para almacenar las versiones de los componentes del 
sistema, construir sistemas a partir de estos componentes y llevar e 1 registro de entregas de 
las versiones del sistema a los clientes. 

Algunas veces, la gestion de configuraciones es parte de un proceso general de gestion de 
la calidad del software (expuesto en el Capitulo 27), donde el mismo gestor comparte las res- 
ponsabilidades de la gestion de la calidad y de laconfiguracion. Los desarrolladores del soft- 
ware entregan este al equipo de garantia de calidad, quienes son responsables de la compro- 
bacion de que el sistema es de calidad aceptable. Aqui comienza a serun sistema controlado, 
lo que significa que los cambios en el sistema tienen que ser acordados y registrados antes de 
ser implementados. Algunas veces, los sistemas controlados se denominan «lineas base» 
puesto que son el punto de inicio para la evolucion controlada. 

Hay muchas razones por las que los sistemas existen en diversas configuraciones. Estas se 
producen para diferentes computadoras, para diferentes sistemas operativos, para incorporar 
funciones especificas del cliente, etcetera (vease laFigura 29.1). Losgestores de la configu- 
racion son responsables de llevar los registros de las diferencias entre las versiones del soft- 
ware, para asegurar que las nuevas versiones se deriven de forma controlada y para entregar 
las nuevas versiones a los clientes correctos en el momento justo. 

La definicion y uso de gestion de configuraciones es esencial para la certificacion de cali- 
dad ISO 9000 y para los estandares C M M y CMMI (Paulk et al, 1995; Ahem et al 2001; Pe- 
ach, 1996). Un ejemplo de tal estandares el IEEE 828-1998, que define un estandarpara los 
planes de la gestion de configuraciones. Dentro de una organizacion, estos estandares se pu- 
blican en un manual de gestion de configuraciones o como parte del manual de calidad. Los 
estandares extemos se utilizan como base para estandares organizacionales detallados y se 
ajustan a un entorno especifico. 



Figura 29.1 

Familias de sistemas. 
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En un proceso tradicional de desarrollo de software basado en el modelo en «cascada» 
(yease el Capitulo 4), el software se entrega al equipo de gestion de configuraciones despues 
de que el desarrollo haya sido completado y se hayan probado los componentes de software. 
Luego este equipo tiene la responsabilidad de construir el sistema completo y gestionar las 
praebas del sistema. Los fallos encontrados durante las pruebas del sistema se devuelven al 
equipo de desarrollo para su reparacion. A continuacion reparan el fallo y entregan una nue- 
va version del componente reparado al equipo de lagarantiadecalidad. Si lacalidad esacep- 
table, este pasa a ser la nueva linea base para el desarrollo del sistema. 

Este modelo, donde el equipo de garantia de calidad controla la integracion del sistema y 
el proceso de pruebas, ha influenciado el desarrollo de estandares para la gestion de configu- 
raciones. Muchos estandares de garantia de calidad suponen que se utiliza el modelo en cas- 
cada para el proceso del software en el desarrollo de sistemas (Bersoff y Davis, 1991). Esto 
significaque los estandares tienen que adaptarse a las aproximaciones modernas de desarro- 
llo de software basadas en especificacion y desarrollo incremental. Hass (Hass, 2003) discu- 
te alguna de estas adaptaciones para los procesos de desarrollo software tales como el des- 
arrollo agil. 

Para ajustarse a este desarrollo incremental, algunas organizaciones han desarrollado un 
nuevo enfoque para gestionar las configuraciones que permite el desarrollo concurrente y las 
pruebas del sistema. Este enfoque se basa en la forma regular (a menudo diaria) de construe - 
cion del sistema completo a partir de sus componentes: 

1 . La organizacion que lleva a cabo el desarrollo fija una hora de entrega (por ejemplo, 
a las 14.00 horas) de los componentes del sistema. Si los desarrolladores tienen nue- 
vas versiones de los componentes que estan escribiendo, entonces deben entregarlos 
todos a esa hora. Los componentes podrian estar incompletos, pero deben ser capaces 
de proveer alguna funcionalidad basica que se pueda probar. 

2. Una nueva version del sistema se construye a partir de estos componentes compilan- 
dolos y vinculandolospara formarun sistema completo. 

3. Entonces el sistema se entrega al equipo de pruebas, que lleva a cabo un conjunto pre- 
definido de pruebas sobre el sistema. Al mismo tiempo, los desarrolladores siguen tra- 
bajando en sus componentes, agregando funcionalidades y reparando los fallos des- 
cubiertos en las praebas previas. 

4. Los fallos encontrados durante las praebas del sistema se documentan y se devuelven 
a los desarrolladores del sistema. Estos reparan dichos fallos en una version ulterior 
del componente. 

La principal ventaja de utilizar construcciones diarias del software es que se incrementan 
las oportunidades de encontrar problemas que surgen a partir de las interacciones al inicio del 
proceso. Mas aun, las construcciones diarias provocan las praebas de las unidades de los com- 
ponentes. Psicologicamente, los desarrolladores se ven presionados «parano derribarel edi- 
ficio», es decir, para no entregar versiones de los componentes que provoquen un fallo en todo 
el sistema. Por lo tanto, son reticentes a entregar nuevas versiones de los componentes que no 
se hayan probado adecuadamente. Si se encuentran fallos en el software y estas se abordan 
durante las praebas de las unidades, se invierte menos tiempo en las praebas del sistema. 

La utilizacion exitosa de las construcciones diarias requiere procesos de gestion del cam- 
bio muy rigurosos para llevar un registro de los problemas encontrados y resueltos. Tambien 
conduce a la gestion de un numero muy grande de versiones del sistema y de los componen- 
tes. Por lo tanto, una buena gestion de configuraciones es esencial para que este enfoque ten- 
ga exito. 
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La gestion de configuraciones en el desarrollo agil y desarrollo rapido no pueden basarse 
en rigidos procedimientos y papeleo burocratico. Aunque estos pueden ser necesarios para 
proyectos grandes o complejos, pueden ralentizar el proceso de desarrollo. Mantener regis- 
tros cuidadosos es esencial para sistemas grandes y complejos desarrollados desde diferentes 
ubicaciones, pero innecesario en proyectos pequenos. En estos proyectos, todos los miembros 
del equipo trabajan juntos en la misma habitacion, y la sobrecarga asociada a mantener los re- 
gistros ralentiza el proceso de desarrollo. Sin embargo, esto no significa que, cuando se re- 
quiera un desarrollo rapido, la gestion de configuraciones deba ser totalmente abandonada. 
Losprocesos agiles utilizanherramientas simples de gestion de configuraciones, como unges- 
tor de versiones y herramientas para la construccion del sistema, que incorporaran algo de 
control. Todos los miembros del equipo tienen que aprender a utilizar estas herramientas y 
asumir las disciplinas que ellas imponen. 

29.1 Planificacion de la gestion de configuraciones 

Un plan de gestion de configuraciones describe los estandares y procedimientos utilizados 
para la gestion de la configuracion. El punto de inicio para desarrollar el plan es un conjunto 
de estandares generales de gestion de la configuracion de toda la compaflia adaptables a cada 
proyecto especifico. El plan de la CM seorganizaenvarioscapitulos que incluyen: 

1. La definicion de lo que se debe gestionar (los elementos de configuracion) y el es- 
quema formal para identificar estas entidades. 

2. Un enunciado de quien toma la responsabilidad de los procedimientos de gestion de 
configuraciones y quien envia las entidades controladas al equipo de gestion de con- 
figuraciones. 

3. Las politicas de gestion de configuraciones utilizadas para gestionar el control de los 
cambios y las versiones. 

4. Una descripcion de las herramientas a utilizar para la gestion de configuraciones y el 
proceso a aplicar cuando se utilizan estas herramientas. 

5. Una definicion de la base de datos de la configuracion que se utilizara para registrar 
la informacion de la configuracion. 

En el plan de la CM se incluye informacion adicional de la gestion del software por parte 
de los proveedores externos y los procesos de auditoria para el proceso de la C M . 

Una parte importante del plan de la CM es la definicion de responsabilidades. Define 
quien es el responsable de la entrega de cada documento o de cada componente de software 
para la garantia de la calidad y la gestion de la configuraciones. Tambien define los revisores 
de cada documento. La persona responsable de la entrega de los documentos no es preciso que 
sea la misma responsable de producir el documento. Para simplificar las inlerfaces, a menu- 
do es conveniente hacer que los gestores de proyectos o los lideres del equipo sean responsa- 
bles de todos los documentos producidos por su equipo. 

29.1.1 Identification de los elementos de configuracion 

En un sistema grande de software, puede haber cientos de modulos de codigo fuente, scripts 
de pruebas, documentos de diseno, etc. Estos son producidos por diferentes personas y, cuan- 
do fueron creados, pudieron tener nombres similares. Para seguir el registro de toda esta in- 
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formacion y encontrar el fichero adecuado cuando este se precise, se necesitara un esquema 
consistente de identificacion para todos los elementos del sistema de gestion de configura- 
ciones. 

Durante el proceso de planificacion de la gestion de configuraciones, se decide exacta- 
mente que elementos (o clases de elementos) se van a controlar. Los documentos o grupos de 
documentos relacionados del control de la configuracion son documentos formales o ele- 
mentos de la configuracion. Normalmente, los planes del proyecto, las especificaciones, los 
diseftos, los programas y los conjuntos de datos de prueba son elementos de la configuracion. 
Todos los documentos que son necesarios para el mantenimiento futuro del sistema deben ser 
controlados por el sistema de control de configuraciones. 

Sin embargo, esto no significa que todos los documentos o archivos deban estar bajo el 
control de configuraciones. Documentos como, porejemplo, documentos tecnicos de trabajo 
que presentan la captura de ideas para el posterior desarrollo, minutas de las reuniones de gru- 
po, bosquejo del plan y propuestas, no tendran relevancia a largo plazo y no seran necesarios 
para el futuro mantenimiento del sistema. 

El esquema de asignacion de nombres a los documentos debe asignarun nombre unico a 
todos los documentos de control de la configuracion. Este nombre debe reflejar el tipo de ele- 
mento, la parte del sistema en la que se utiliza y el creador del elemento, entre otros. En su 
esquema de nombres, tambien debera reflejar las relaciones entre elementos para asegurarque 
los documentos relacionados tengan una raiz comun de su nombre. Esto conduce a un esque- 
ma de asignacion de nombres j erarquico. Algunos ejemplos de los nombres son: 

PCL-TCX)LS/EDIT/FORMS/DISPLAY/AST-INTERFACE/CODE 
PCL-TOOLS/EDIT/HELP/Q1JERY/HELPFRAMES/FR- 1 

La parte inicial del nombre es el nombre del proyecto, PCL-TOOLS. En este proyecto, 
existen cuatro herramientas diferentes; el nombre de la herramienta (EDIT) se utiliza como 
la siguiente parte del nombre. Cada herramienta esta compuesta de modulos nombrados de 
forma distinta, cuyos nombres pasan a ser parte del idenlificador (FORMS, HELP) . Este pro- 
ceso de descomposicion continua hasta que se haga referencia a los documentos formales en 
el nivel base (vease la Figura29.2). Las hojas de lajerarquia de la documentacion son ele- 
mentos de configuracion formales. La Figura 29.2 muestra que se requieren tres documentos 
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formales para cada componente: una descripcion de los objetos (OBJECTS), el codigo del 
componente (CODE) y un conjunto de pruebas para el codigo (TEST). Elementos como la 
ayuda son tambien gestionados y tienen diferentes nombres (FR- 1 , en el ejemplo anterior). 

La asignacion de nombres jerarquica es simple y facil de entender, y a veces copia la es- 
tructura de directorios utilizada para almacenar los archivos del proyecto. Sin embargo, re- 
flejan la estructura del proyecto cuando se desarrollo el software. Los nombres de los ele- 
mentos de configuracion asociados a un proyecto particular pueden reducir las oportunidades 
de reutilizacion. Puede ser muy dificil encontrar componentes relacionados (por ejemplo, to- 
dos los componentes desarrollados por el mismo programador) donde el esquema de nombres 
no refleja esta relacion. 

29.1.2 La base de dates de conflguraclones 

La base de datos de configuraciones se utiliza para registrar toda la informacion relacionada 
con las configuraciones y sus elementos. Sus funciones principales son ayudar a la evaluacion 
del impacto de los cambios en el sistema y proveer informacion de la gestion acerca del pro- 
ceso de la C M . Ademas de definir el esquema de la base de datos de la configuracion, como 
parte del proceso de planificacion de la CM tambien se deben definir los formularios y los pro- 
cedimientos para registrar y recuperar la informacion del proyecto. 

Una base de datos de configuraciones no incluye informacion acerca de los elementos de 
configuracion. Registra informacion acerca de los usuarios de los componentes, los clientes 
del sistema, plataformas de ejecucion, cambios propuestos, etc. Le debe serposible suminis- 
trar respuestas a una variedad de consultas acerca de las configuraciones del sistema. Algu- 
nas consultas podrian ser: 

1 . <,A que clientes se les ha entregado una version particular del sistema? 

2. iQue configuracion de hardware y del sistema operativo se requiere para ejecutar una 
version dada del sistema? 

3. ^Cuantas versiones del sistema se han creado y cuales son sus fechas de creacion? 

4. ^Que versiones del sistema se ven afectadas si se cambia un componente particular? 

5. ^Cuantas peticiones de cambios estan pendientes para una version particular? 

6. ^Cuantos fallos declarados existen en una version particular? 

De forma ideal, la base de datos de configuraciones se integra en el sistema de gestion de 
las versiones utilizado para almacenar y gestionar los documentos formales del proyecto. Este 
enfoque, apoyado por algunas herramientas CASE integradas, hace posible vincular los cam- 
bios de forma directa con los documentos y componentes afectados por el cambio. Se da man- 
tenimiento a los vinculos entre los documentos, como los documentos de diseno y el codigo 
del programa, con el fin de que sea relativamente facil encontrar todo lo que debe modificar- 
se cuando se propone un cambio. 

Sin embargo, las herramientas C A S E integradas para la gestion de configuraciones sonca- 
ras. Muchas companias no las utilizan, sino que mantienen su base de datos de configuracio- 
nes como un sistema independiente de su sistema de control de versiones. Los elementos de 
la configuracion se almacenan en archivos o en el sistema de gestion de versiones como el 
CVS (Berliner, 1990), que se vera mas adelante en este capitulo. 

Esta base de datos de configuraciones almacena informacion de los elementos de la con- 
figuracion y hace referencia a sus nombres de archivos en el sistema de gestion de versiones. 
Aunque este es un enfoque relativamente economico y flexible, su desventaja es que los ele- 
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tnentos de la configuracion se pueden cambiar sin que la base de datos de configuraciones ten- 
ga conocimiento. Por lo tanto, no se puede estar seguro de que la base de datos de la confi- 
guracion sea una descripcion actualizada del estado del sistema. 



El cambio es un hecho en la vida de los sistemas de software grandes. Como se comento en 
los primeros capitulos, las necesidades organizacionales y los requerimientos cambian durante 
el tiempo de vida de un sistema. Esto significa que habra que hacer los correspondientes cam- 
bios al software del sistema. Para asegurarse de que estos cambios se hagan de forma correc- 
ta, se necesitara un conjunto de herramientas de soporte para los procedimientos de gestion 
de cambios. 

Los procedimientos de gestion de cambios se ocupan del analisis de costes y beneficios de 
los cambios propuestos, aprobando aquellos cambios que merecen la pena y registrando los 
componentes del sistema que se tienen que cambiar. El proceso de gestion de cambios (vea- 
se la Figura 29.3) se lleva a cabo cuando el software o la documentacion asociada se pone bajo 
el control del equipo de gestion de configuraciones. 

Laprimera etapadel proceso de gestion del cambio es completarun formulario de solici- 
tud de cambios (CRF) en el cual el solicitante sefiala los cambios requeridos en el sistema. 
Ademas de registrar los cambios requeridos, el CRF registra las recomendaciones pertinen- 
tes al cambio, los costes estimados del cambio y las fechas en las que se solicita, prueba, im- 
plementay validael cambio. Tambien incluye una seccion donde el analista sefiala como im- 
plementar el cambio. 

En la Figura 29.4 se muestraun ejemplo de un formulario de solicitud de cambios, el cual 
se encuentra parcialmente rellenado. Por lo general, los formularios de solicitud de cambios 
se definen durante el proceso de planificacion de la C M . Este es un ejemplo de CRF que pue- 
de utilizarse en sistemas grandes y complejos. Para pequefios proyectos, recomiendo que las 
peticiones de cambios sean formalmente registradas, pero el CRF debe centrarse mas en la 
descripcion del cambio requerido y menos en la implementacion. El ingeniero que hace el 
cambio decide como implementarlo en estas situaciones. 
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El proceso de 
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Una vez emitido el formulario, se registra en la base de datos de configuraciones. Se anali- 
za la peticion de cambios para comprobar que el cambio solicitado es necesario. Algunas peti- 
ciones de cambio se deben a los malentendidos mas que a los fallos del sistema y, por lo tanto, 
no es necesario modificarel sistema. Otras se refieren a fallos ya conocidos. Si el analisis des- 
cubre que el cambio solicitado es invalido, estaduplicado o yaha sido considerado, el cambio 
se rechaza. La razon del rechazo se devuelve a la persona que emitio la solicitud del cambio. 

Para cambios validos, la siguiente etapa del proceso es evaluar y asignar costes al cambio. 
Se comprueba el impacto del cambio en el resto del sistema. Se lleva a cabo un analisis tec- 
nico de como implementar el cambio. Esto implica identificar todos los componentes afecta- 
dos por el cambio utilizando la base de datos de configuraciones y el codigo fuente. Si hacer 
los cambios implica hacer mas cambios en otros lugares del sistema, se incrementaran los cos- 
tes de implementacion del cambio. A continuacion, se valoraran los cambios requeridos en 
los modulos del sistema. Finalmente, se estima el coste del cambio, teniendo en cuenta los 
costes de modificar estos componentes. 

El consejo de control de cambios (CCB) revisay aprueba todas las peticiones de cambios 
amenos que el cambio simplemente comprenda la correccion de errores menores en los des- 
pliegues de la pantalla, las paginas web o en los documentos. El CCB considera el impacto 
del cambio desde el punto de vista estrategico y organizacional mas que desde el punto de vis- 
ta tecnico. Decide si el cambio se justifica economicamente y si existen buenas razones or- 
ganizacionales para aceptarlo. 

La denominacion «consejo de control de cambios» implica que un grupo toma las deci- 
siones del cambio. Los proyectos militares requieren consejos de control de cambios estruc- 
turados formalmente, que incluyen a los clientes y los proveedores. Sin embargo, para pro- 
yectos pequenos o de medio tamano, el consejo de control de cambios simplemente se 
compone de un gestor de proyectos mas uno o dos ingenieros que no estan directamente in- 
volucrados en el desarrollo del software. En algunos casos, existe solo un revisor del cambio 
que aconseja si los cambios sonjustificables. 
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La gestion de cambios para sistemas estandar de software debe ser manejada de una for- 
ma ligeramente diferentea los sistemas hechos amedida. Enestos sistemas estandar, los clien- 
tes no estan directamente implicados, por lo que un cambio en el negocio del cliente no nos 
afecta. Las peticiones de cambio estan generalmente asociadas con errores en el sistema que 
han sido descubiertos durante las pruebas del sistema o por nuestros clientes una vez que ha 
sido entregado el mismo. Los clientes pueden enviar los informes de error a traves de una pa- 
gina web o pore-mail. Un equipo de gestion de errores comprobara que los errores remitidos 
son validos y los traducira a peticiones de cambio formales del sistema. Los cambios tienen 
que ser priorizados para su implementacion y los errores no pueden ser reparados si los cos- 
tes de reparacion son muy elevados. 

Cuando se crean las nuevas versiones del sistema por medio deunaconstrucciondiaria, se 
utiliza un proceso de gestion del cambio sencillo. Los problemas en los cambios aun deben 
registrarse, pero los cambios que solo afectan a los componentes y modulos individuales no 
necesitan ser evaluados de forma independiente. Se pasan directamente al desarrollador del 
sistema. Este los acepta o indica por que ya no se requieren. Los cambios que afectan a los 
modulos del sistema producidos por diferentes equipos de desarrollo son evaluados poralgu- 
na autoridad de control del cambio quien decide si se implementan. 

En algunos metodos agiles, como programacion extrema, los clientes son directamente im- 
plicados en decidir cuando un cambio debe ser implementado. Cuando ellos proponen un 
cambio en los requerimientos del sistema, trabajan con el equipo en evaluar el impacto del 
cambio y deciden cuando deben tenerprioridad respecto a los planes establecidos para el pro- 
ximo incremento del sistema. Sin embargo, los cambios que atanen a mejoras del software se 
dejan a discrecion de los programadores que trabajan en el sistema. La reconstruccion, don- 
de el software es mejorado continuamente, no se ve como una sobrecarga, sino como una par- 
le necesaria del proceso de desarrollo. 

Conforme se cambian los componentes del software, se da mantenimiento al registro de 
los cambios realizados a cada componente. A veces estos se denominan historial del compo- 
nente. La mejor forma de dar mantenimiento a tales registros es por medio de una cabecera 
estandarizada, ubicada al inicio del componente (vease la Figura 29.5). Este se refiere a la so- 
licitud de cambio asociada como el cambio del software. Pueden escribirse scripts sencillos 
que analicen todos los componentes y procesen los historiales para generar informes de cam- 
bios para los diversos componentes. Para las paginas web se puede utilizaruna aproximacion 
similar. Para documentos publicados, los registros de cambios de cada version son general- 
mente mantenidos en una portada del documento. 
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293 Gestlon de verslones y entregas 

La gestion de las versiones y entregas es el proceso de identificar y mantener los registros de 
las diversas versiones y entregas de un sistema. Los gestores de las versiones disenan proce- 
dimientos para asegurar que las diversas versiones de un sistema se puedan recuperar cuando 
se requieran y que no se cambien de forma accidental por parte del equipo de desarrollo. Tam- 
bien trabajan con los responsables de marketing y con los clientes de sistemas personaliza- 
dos, en planificar las entregas y distribuciones. 

Una version de un sistema es una instancia de un sistema que difiere, de alguna mane- 
ra, de otras instancias. Las nuevas versiones de un sistema tienen diferente funcionalidad, 
mejor rendimiento o incorporan reparaciones de los fallos del sistema. Algunas versiones 
son funcionalmente equivalentes pero disenadas para diferentes configuraciones de hard- 
ware y software. Si solo existen pequeflas diferencias entre las versiones, estas se denomi- 
nan variantes. 

Una entrega de un sistema es una version que se distribuye a los clientes. Cada entrega 
incluye nueva funcionalidad o esta concebida para diferentes plataformas de hardware. 
Siempre existen mas versiones de un sistema que las entregas, puesto que las versiones se 
crean dentro de una organizacion para el desarrollo interno o pruebas y nunca se entregan 
a los clientes. 

En la actualidad, la gestion de versiones se apoya siempre en herramientas CASE, como 
se explica en la Seccion 29.5. Estas herramientas administran el almacenamiento de cada ver- 
sion del sistema y controlan el acceso a los componentes del sistema. Se apoyan en el siste- 
ma para llevar a cabo las ediciones. Cuando los componentes se reintroducen en el sistema, 
se crea una nueva version y el sistema de gestion de versiones le asigna un identificador. A 
pesar de que las herramientas difieren obviamente de funcionalidades y de interfaz, la base de 
todas estas herramientas de soporte es la gestion de versiones. 

29.3.1 Identification de versiones 

Para crear una version particular del sistema, se tienen que especificar las versiones de cada 
uno de los componentes que deben incluirse en el. Dentro de un sistema de software grande, 
existen cientos de componentes de software, cada uno de los cuales tiene varias versiones di- 
ferentes. Debe definirse una forma no ambigua de identificar cada version de los componen- 
tes para asegurar que se incluyen los componentes adecuados en el sistema. Sin embargo, no 
se puede utilizarel nombre del elemento de configuracion para identificar las versiones debi- 
do a que hay diferentes versiones para cada elemento de configuracion. 

Existen tres tecnicas basicas utilizadas para la identificacion de componentes: 

1. Numeration de las versiones. A 1 componente se le asigna un numero de version ex- 
plicitoy unico. Este es el esquemade identificacion mas utilizado. 

2. Identificacion basada en atributos. Cada componente tiene un nombre (como el nom- 
bre utilizado para nombrar los elementos de configuracion, que no es unico a lo largo 
de las versiones) y un conjunto asociado de atributos para cada version del componente 
(EstubHery Casallas, 1994). Por lo tanto, los componentes se identifican por su nom- 
bre y por los valores de los atributos. 

3. Identification orientadaal cambio. Cada sistema senombra a partirde los atributos, 
pero tambien se asocia con una o mas solicitudes de cambios (Munch et ai., 1993). 
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Cada version del documento es creada en respuesta a una o mas peticiones de cam- 
bios. La version del sistema se identifica por el conjunto de los cambios implementa- 
dos en el componente. 

Numeration deversiones 

En un esquema sencillo de numeracion de versiones, al nombre del componente o del siste- 
ma se le anade un numero de version. Por lo tanto, sepuede hablarde Solaris 4.3 (version 4.3 
del sistema Solaris) y la version 1.4 del componente getToken. La primera version se deno- 
mina 1.0, las subsiguientes versiones son 1.1, 1.2 y asi sucesivamente. En algunaetapa, se en- 
trega una nueva version (version 2.0) y el proceso comienza otravez en la version 2.1. El es- 
quema es lineal y se basa en la suposicion de que las versiones del sistema se crean en 
secuencia. Muchas herramientas de gestion de versiones (vease la Seccion 29.5) como RCS 
(Tichy, 1985)yCVS (Berliner, 1990) permiten esta forma de identificacion de versiones. 

En la Figura 29.6 se muestra este enfoque y la derivacion de algunas versiones diferentes del 
sistema a partir de versiones previas. Las flechas en este diagrama apuntan desde la version fuen- 
te hasta una nueva version del sistema creada a partir de la fuente. Observe que la derivacion de 
versiones no es necesariamente lineal y las versiones con numeros de version consecutivos se 
producen a partir de diferentes lineas base. Esto se muestra en la Figura 29.6, donde la ver- 
sion 2.2 se crea a partir de la version 1.2 en lugarde la version 2.1. Enprincipio, cualquier ver- 
sion existente se puede utilizar como un punto de inicio para una nueva version del sistema. 

Este esquema es sencillo pero requiere una buena gestion de la informacion para llevar a 
cabo los registros de las diferentes versiones y las relaciones entre los cambios propuestos y 
versiones del sistema. Por ejemplo, las versiones 1.1 y 1.2 deun sistema pueden diferir en que 
la version 1.2 ha utilizado una libreria grafica diferente. En consecuencia, se necesitara man- 
tener registros en la base de datos de configuraciones que describan cada version y por que 
ha sido producida. Puede necesitarse vincular explicitamente la peticion de cambios con las 
diferentes versiones de cada componente. 

Identificacion basada en atributos 

Un problema fundamental con los esquemas explicitos de asignacion de nombres de las ver- 
siones es que no reflejan los muchos atributos diferentes utilizados para identificar las ver- 
siones. Ejemplos de estos atributos que permiten la identificacion son: 

• Elcliente 

• El lenguaje de desarrollo 



Figura 29.6 
Estructura 
de derivacion 
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• El estado del desarrollo 

• La plataforma de hardware 

• La fecha de creacion 

Si cada version es identificada por un conjunto unico de atributos, es facil agregar nuevas 
versiones derivadas a partir de cualquiera de las versiones existentes. Estas se identifican uti- 
lizando un conjunto unico de valores de los atributos. Comparten muchos de estos valores con 
sus versiones padre, por lo que se conserva la relacion entre las versiones. Las versiones se 
recuperan especificando los valores de los atributos requeridos. Las funciones de los atribu- 
tos permiten consultas como «la version creada mas recientemente», «la version creada en fe- 
chas dadas», etcetera. Por ejemplo, la version del sistemade software AC 3 D desarrollada en 
Java para Windows XP en enero de 2003 se identifica como: 

AC3D (lenguaje = Java, plataforma = XP, fecha = Ene2003) 

Usando la especificacion general de los componentes en AC3D, la herramienta de gestion 
de versiones selecciona los componentes que tienen los atributos «Java», «XP» y «Ene2003». 

La identificacion basada en atributos se implementa directamente por el sistema de ges- 
tion de versiones, utilizando los atributos de los componentes mantenidos en la base de datos 
del sistema. Alternativamente, se puede implementar un sistema de identificacion de atribu- 
tos como una capa superior de un esquema de numeracion de versiones oculto. La base de da- 
tos de configuraciones mantiene los vinculos entre los atributos de identificacion y el sistema 
subyacente y las versiones del componente. 

Identificacion orientada al cambb 

La identificacion basada en atributos de las versiones del sistema elimina algunos de los pro- 
blemas de la recuperacion de versiones encontrados en los esquemas sencillos de numeracion. 
Sin embargo, para recuperar una version, se tienen que conocer los atributos asociados. Mas 
aun, se necesitautilizarun sistemade gestion de cambios independiente para descubrir las re- 
laciones entre las versiones y los cambios. 

La identificacion orientada al cambio se utiliza mas para identificar los sistemas que los 
componentes. Las versiones de los componentes individuales estan ocultas a los usuarios del 
sistema de la C M . Cada cambio del sistema propuesto tiene un conjunto de cambios asocia- 
do que describe los cambios realizados a los diferentes componentes del sistema para imple- 
mentar este cambio. Los conjuntos de cambios se aplican en secuencia, por lo que, al menos 
en principio, se puede crear una version del sistema que incorpore cualquier conjunto arbi- 
trario de cambios. Por ejemplo, los cambios incorporados para adaptar el sistema a Linux en 
lugar de Solaris, seguido de los cambios necesarios para incorporar un nuevo sistema de base 
de datos. De igual forma, a los cambios Linux/Solaris pueden seguirlos las modificaciones 
para traducir la interfaz de usuario de ingles a italiano. 

En la practica, por supuesto, no es posible aplicar conjuntos arbitrarios de cambios a un 
sistema. Los diversos conjuntos de cambios pueden ser incompatibles, por lo que aplicar un 
conjunto de cambios A seguido de un conjunto de cambios D puede crear un sistema no va- 
lido. Mas aun, los conjuntos de cambios pueden entrar en pugna debido a que los diversos 
cambios afectan al mismo codigo del sistema. Para afrontar estas dificultades, las herra- 
mientas de gestion de versiones que apoyan la identificacion orientada a cambios permiten 
especificar las reglas de consistencia que delimitan las formas de combinar los conjuntos de 
cambios. 
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29.3.2 Gestion de entregas 

Una entrega del sistema es una version del sistema que se distribuye a los clientes. Los ges- 
tores de entregas del sistema son los responsables de decidircuando se entrega el sistema, de 
gestionarel proceso de creacion de las entregas y de los medios de distribucion y documen- 
tacion de la entrega para asegurar que se puedan recuperar de la misma forma en que se dis- 
tribuyeron, en caso necesario. 

Una entrega del sistema no es solo el codigo ejecutable del sistema. Las entregas tambien 
incluyen: 

1 . Archivos de configuration, que definen como configurar el sistema para instalaciones 

especlficas. 

2. Los archivos de datos necesarios para el funcionamiento del sistema. 

3. Elprograma de instalacion utilizado para ayudar a instalar el sistema en el hardware 
destino. 

4. La documentation electronicay en papel que describe al sistema. 

5. El embalajey la publicidad asociados di sefiado s para esta entrega. 

Los administradores de las entregas no pueden suponerque los clientes siempre instalaran 
las nuevas versiones del sistema. Algunos usuarios del sistema estan a gusto con una version 
existente el sistema. Consideran que no vale la pena gastar en cambiar a una nueva entrega. 
Por lo tanto, las nuevas entregas del sistema no pueden depender de la existencia de entregas 
previas. Consideremos el siguiente escenario: 

1. La entrega 1 de un sistema se distribuye y se pone en funcionamiento. 

2. La entrega 2 requiere la instalacion de nuevos archivos de datos, pero algunos clien- 
tes no necesitan los recursos de la entrega 2, por lo que conservan la entrega 1 . 

3. La entrega 3 requiere los archivos de datos instalados en la entrega 2 y no agrega nue- 
vos archivos de datos. 

El distribuidor de software no puede suponer que los archivos requeridos para la en- 
trega 3 se han instalado en todos los lugares. Algunos sitios van directamente de la en- 
trega 1 a la entrega 3, saltandose la entrega 2. Algunos sitios pueden haber modificado 
los archivos de datos asociados con la version 2 para adaptarlos a circunstancias locales. 
Por lo tanto, los archivos de datos deben ser distribuidos e instalados con la version 3 del 
sistema. 

Toma de declsiones de la entrega 

Preparar y distribuir una entrega del sistema es un proceso costoso, particularmente para 
los productos de software de mercados en masa. Si las entregas son muy frecuentes, los 
clientes pueden no actualizarse a las nuevas, especialmente si no son gratuitas. Si las en- 
tregas son infrecuentes, se puede perder cuota de mercado puesto que los clientes consi- 
deran sistemas alternativos. Esto, por supuesto, no es aplicable al software desarrollado es- 
pecificamente para una organizacion. Sin embargo, para este tipo de software, las entregas 
infrecuentes significan un crecimiento divergente entre el software y los procesos de ne- 
gocios que pretenden apoyar. 

Las decisiones sobre cuando entregar una nueva version del sistema estan dirigidas por va- 
rios factores tecnicos y organizacionales, como se muestra en la Figura 29.7. 
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Figura 29.7 
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Creadon de la entrega 

La creacion de las entregas es el proceso de crear una coleccion de archivos y documentacion 
que incluyen todos los componentes de la entrega del sistema. El codigo ejecutable de los pro- 
gramas y lodos los archivos de datos asociados se recogen e identifican. Se describen las con- 
figuraciones diferentes para hardware y sistemas operativos y las instrucciones para los clien- 
tes que necesiten configurar sus propios sistemas. Si se entregan manuales, las copias 
electronicas deben almacenarse con el software. Se deben escribir las guias para la instalacion. 
Finalmente, cuando toda la informacion esta disponible, se prepara un disco de entrega para 
la distribucion. 

Actualmente, los discos opticos (CD-ROM y DVD), que almacenan desde 600 MBytes 
hasta 4 GBytes, son el medio de distribucion normal para la entrega del sistema. Adicional- 
mente, muchos productos de software tambien se entregan a traves de Internet. Sin embargo, 
muchas personas, encuentran muy largo el tiempo de descarga de archivos y prefieren la dis- 
tribucion en CD-ROM. 

La distribucion de las nuevas entregas tiene asociados unos altos costes de marketing y de 
empaquetado, por lo que los vendedores crean usualmente nuevas entregas para nuevas pla- 
taformas o cuando se anaden funcionalidades nuevas significativamente. Ellos cobran a los 
usuarios por este software nuevo. Cuando se descubren problemas en una entrega, los vende- 
dores usualmente hacen parches, que se pueden descargar via web, para reparar el software 
existente. 

Ademas de los costes de encontrar y descargar la nueva entrega, el problema es que mu- 
chos clientes nunca descubren la existencia de estos parches o no tienen los conocimientos 
tecnicos para instalarlos. En lugar de hacer esto, pueden continuar utilizando el existente, fa- 
llando el sistema con los consiguientes riesgos para sus negocios. En algunas situaciones, en 
que el parche es disefiado para reparar fallos de seguridad, el riesgo de no hacer la instalacion 
del parche puede significar que el negocio sea susceptible de ataques extemos. 
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Documentacion de las entregas 

Cuando se produce la entrega de un sistema, debe estar documentada para asegurar que se 
puede reconstruir exactamente en el futuro. Esto es particularmente importante para los sis- 
temas personalizados de larga vida. Los clientes utilizan una sola entrega de estos sistemas 
por muchos anos y requieren cambios especificos para una entrega particular del software mu- 
cho despues de la fecha de entrega original. 

Para documentar una entrega, se tienen que registrar las versiones especificas de los com- 
ponentes del codigo fuente utilizados para crear el codigo ejecutable. Tambien se deben man- 
tenercopias del codigo fuente y ejecutable y todos los archivos de datos y de configuracion. 
Tambien se deben registrar las versiones del sistema operativo, las bibliotecas, los compila- 
dores y otras herramientas utilizadas para construir el sistema. Estos pueden requerirse para 
construir exactamente el mismo sistema en alguna fecha posterior. En estos casos, las copias 
de las plataformas de software y las herramientas tambien se almacenan en un sistema de ges- 
tion de versiones. 

29.4 Construccion del sistema 

La construccion del sistema es el proceso de compilar y vincular los componentes del soft- 
ware en un programa que se ejecuta en una configuracion particular. Cuando se construye un 
sistema a partir de sus componentes, se tienen que hacer las siguientes preguntas: 

1. ^Todos componentes de un sistema se incluyen en las instrucciones de la construc- 
cion? 

2. ^La version apropiada de cada componente se incluye en las instrucciones de la cons- 
truccion? 

3. ^Estan disponibles todos los archivos de datos requeridos? 

4. Si los archivos de datos estan asociados a componentes, ^el nombre que se utiliza es 
el mismo que el nombre de los archivos de datos en la maquina donde se ejecutara el 
software? 

5. ^Estan disponibles las versiones adecuadas del compilador y otras herramientas re- 
queridas? Las versiones actuales de las herramientas de software pueden ser incom- 
patibles con las versiones anteriores utilizadas para desarrollar el sistema. 

Hoy en dia, las herramientas de la CM se utilizan para automatizar el proceso de cons- 
truccion del sistema. El equipo de la CM escribe una secuencia de comandos (script) que 
define las dependencias entre los diferentes componentes del sistema. Tambien especifica 
las herramientas utilizadas para compilar y vincular los componentes del sistema. La he- 
rramienta de construccion del sistema interpreta dicha secuencia de comandos y llama a 
otros programas requeridos para construir el sistema ejecutable. Esto se ilustra en la Fi- 
gura 29.8. En algunos entornos de programacion (como los entornos de desarrollo de Ja- 
va), el script para construir el sistema se crea automaticamente analizando el codigo fuen- 
te y estableciendo los componentes utilizados. Por supuesto, en esta situacion, el nombre 
de los componentes almacenados tiene que ser el mismo nombre que el componente del 
programa. 

Las dependencias entre los componentes se especifican en la secuencia de comandos de 
construccion, por lo que el sistema de construccion decide cuando los componentes deben re- 
compilarse y cuando se puede reutilizarel codigo objeto existente. En muchas herramientas. 
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Figura 29.8 Construccion del sistema. 



las dependencias de la secuencia de comandos de construccion se especifican como depen- 
dencias entre los archivos en los cuales los componentes de codigo fuente se almacenan. Sin 
embargo, cuando existen multiples archivos de codigo fuente representando a las diferentes 
versiones de los componentes, algunas veces no se ve claramente que archivos fuente se uti- 
lizaron para derivar los componentes del codigo objeto. Esta confusion aparece cuando la co- 
rrespondencia entre los archivos de codigo fuente y objeto comparten el mismo nombre pero 
diferente sufijo (por ejemplo, .c y .o). La unica forma de evitar este problema es que las he- 
rramientas de gestion de versiones y de construccion del sistema esten integradas. 



29.5 Herramientas CASE para gestion de configuraciones 

Los procesos de gestion de configuraciones por lo general estan estandarizados e involucran 
la aplicacion de procedimientos predefinidos. Requieren la gestion cuidadosa de grandes can- 
tidades de datos, y la atencion a los detalles es esencial. Cuando se construye un sistema a par- 
tir de las versiones de los componentes, un simple error en la gestion de configuraciones pue- 
de implicarque el software no trabaje de forma adecuada. En consecuencia, las herramientas 
CASE de apoyo son esenciales para la gestion de configuraciones, y desde los 70 se ha pro- 
ducido un gran numero de diferentes herramientas que abordan diferentes areas de la gestion 
de configuraciones. 

Estas herramientas pueden ser combinadas para crear entornos de trabajo de gestion de 
configuraciones que soporten todas las actividades C M . Hay dos tipos de entornos de traba- 
jo CM: 

1 . Entornos de trabajo abiertos. Las herramientas para cada etapa del proceso CM son 
integradas de acuerdo con procedimientos organizacionales estandar. Hay muchas he- 
rramientas CM comerciales y open-source disponibles para propositos especificos. La 
gestion de cambios puede llevarse a cabo con herramientas de seguimiento (bug-trac- 
king) como Bugzilla, la gestion de versiones a traves de herramientas como RCS 
(Tichy, 1985) o C V S (Berliner, 1990), y la construccion del sistema con herramientas 
como Make (Feldman, 1979; Oram y Talbott, 1991) o Imake (Dubois, 1996). Todas 
estas herramientas son open-source y estan disponibles de forma gratuita. 

2. Entornos integrados. Estos entornos ofrecen facilidades integradas para gestion de 
versiones, construccion del sistema o seguimiento de los cambios. Por ejemplo, el pro- 
ceso de gestion de Cambios Unificado de Rational se basa en un entorno CM integra- 
do que incorporaClearCase (White, 2000) para la construccion y gestion de versiones 
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del sistema y ClearQuest para el seguimiento de los cambios. Las ventajas de los en- 
tomos CM integrados es que el intercambio de dalos es sencillo, y que el entomo in- 
cluye una base de datos CM integrada. Los entornos integrados S C M provienen de sis- 
temas antiguos como Lifespan (Whitgift, 1991) para gestion de cambios y DSEE 
(Leblang y Chase, 1987) para gestion de versiones y construccion del sistema. Sin em- 
bargo, los entornos integrados CM son complejos y costosos, y muchas organizacio- 
nes prefieren utilizar herramientas individuales mas simples y economicas. 

Muchos sistemas grandes son desarrollados desde diferentes lugares, y necesitan herra- 
mientas S C M que soporten el trabajo desde multiples lugares con multiples almacenes de da- 
tos para los elementos de configuracion. Mientras muchas herramientas S CM estan disena- 
das para trabajar desde un unico lugar, otras como CVS facilitan el trabajo desde multiples 
sitios. 

29.5.1 Apoyo a la gestion de cambios 

Cada persona involucrada en el proceso de gestion de cambios es responsable de alguna ac- 
tividad. Una vez que completa esta actividad pasa los formularios y elementos de configura- 
cion asociados a otra persona. La naturaleza de procedimiento de este proceso significa que 
un cambio en el modelo del proceso se disena e integra con un sistema de gestion de versio- 
nes. Entonces este modelo se interpreta para que los documentos correctos se pasen a la per- 
sona indicada en el momento justo. 

Hay varias herramientas de gestion de cambios disponibles, desde herramientas relativa- 
mente simples, open-source como Bugzilla hasta sistemas absolutamente integrados como 
Racional ClearQuest. Estas herramientas proveen alguna o todas de las siguientes caracteris- 
ticas de apoyo al proceso: 

1 . Un editor de formularios que permite cambiar los formularios propuestos a crear y re- 
llenar por las personas que hacen las peticiones de cambios. 

2. Un sistema de flujo de trabajo que permiten al equipo de la CM especificar las perso- 
nas que deben procesar las solicitudes de peticiones de cambio y el orden del proce- 
samiento. Este sistema tambien pasa de forma automatica los formularios a las perso- 
nas indicadas en el momento justo e informa a los miembros relevantes del equipo del 
progreso del cambio. El correo electronico se utilizapara suministrar actualizaciones 
del progreso a aquellos involucrados en el proceso. 

3. Una base de datos de cambios que se utiliza para gestionar todas las propuestas de 
cambios y que puede vincularse al sistema de gestion de versiones. Por lo general, se 
proveen las caracteristicas de consulta que permiten al equipo de la CM encontrarpro- 
puestas especificas de cambios. 

4. Un sistema de gestion de informes de cambios que genera informes sobre el estado de 
la peticiones de cambio recibidas. 

29.5.2 Soporte para gestion de versiones 

La gestion de versiones implica gestionar grandes cantidades de informacion para asegurar que 
tos cambios en el sistema se registren y controlen. Las herramientas de gestion de versiones con- 
trolan un repositorio de elementos de configuracion donde el contenido de ese repositorio es in- 
mutable (no cambia). Para trabajar sobre un elemento de la configuracion, debe extraerse del re- 
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positorio y colocarlo en un directorio de trabajo. Despues de hacer los cambios en el software, 
se introducira de nuevo en el repositorio, creandose automaticamente una nueva version. Todos 
los sistemas de gestion de versiones proveen un conjunto basico de capacidades comparables 
aunque algunos son mas sofisticados que otros. Ejemplos de estas capacidades son: 

1. Identification de versionesy entregas, A las versiones gestionadas se les asignan iden- 
tificadores cuando se introducen en el sistema. Varios sistemas permiten los diferen- 
tes tipos de identificacion de versiones tratados en la Seccion 29.3.1. 

2. Gestidn del almacenamiento. Para reducir el espacio de almacenamiento requerido por 
las diferentes versiones, los sistemas de gestion de versiones proveen las caracteristi- 
cas de gestion del almacenamiento donde las versiones se describen por sus diferen- 
cias a partir de alguna version maestra. Las diferencias entre las versiones se repre- 
sentan con una delta que encapsula las instrucciones requeridas para reconstruir la 
version asociada del sistema. Esto se ilustra en la Figura 29.9, que muestra como se 
aplican las deltas inversamente a la ultima version de un sistema para reconstruir las 
versiones anteriores. 

3. Registro del historial del cambio. Todos los cambios realizados al codigo de un siste- 
ma o componente se registran y son listados. En algunos sistemas, estos cambios se 
utilizan para seleccionar una version particular del sistema. 

4. Desarrollo independiente. Las diferentes versiones de un sistema se pueden desarro- 
llar en paralelo y cada version cambia de forma independiente. Por ejemplo, la entre- 
ga 1 se modifica despues del desarrollo de la entrega 2 agregando nuevas deltas de ni- 
vel 1. El sistema de gestion de versiones mantiene un registro de los componentes que 
han sido extraidos para su edicion y asegura que no interfieran los cambios que dife- 
rentes desarrolladores hayan hecho a los mismos componentes. Algunos sistemas solo 
permiten que se extraiga una instancia de un componente para su edicion; otros re- 
suelven los conflictos potenciales cuando los componentes editados se reintroducen en 
el sistema. 

5. Apoyo alproyecto. El sistema puede soportarmultiplesproyectos asi como multiples 
archivos. En sistemas de apoyoaproyectos, comoCVS , esposible introduciry extraer 
todos los ficheros asociados a un proyecto en lugar de tener que trabajar con un solo 
fichero a la vez. 



29.5.3 Apoyo a la construccion del sistema 

La construccion de sistemas es un proceso intensivo de computacion. Compilary vincular to- 
dos los componentes de un sistema grande puede llevar varias horas. Puede haber cientos de 
archivos involucrados con la consecuente posibilidad de errores humanos si estos se compi- 
lan y vinculan de forma manual. Las herramientas de construccion de sistemas automatizan 
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elproceso de construccion para reducir los errores humanos potenciales y, donde seaposible, 
disminuir el tiempo requerido para la construccion del sistema. 

Las herramientas de construccion del sistema pueden ser independientes como las deriva- 
das de la utilidad MAKE de Unix (Oran y Talbott, 1991) o integradas con las herramientas de 
gestion de versiones. Las caracteristicas suministradas por las herramientas CASE de cons- 
truccion de sistemas son: 

1. Una dependencia del lenguaje de especificacion o del interprete asociado. Las de- 

pendencias de los componentes se describeny se disminuye la recompilacion. Esto se 
explica mas adelante en esta seccion. 

2. Selection de herramientas y apoyo a la instantiation. Se especifican e instancian, 
como se requiera, los compiladores y otras herramientas de procesamiento utilizadas 
para procesar los archivos de codigo fuente. 

3. Compilation distribuida. Algunos constructores de sistemas, especialmente aquellos 
que son parte de los sistemas integrados de la C M , permiten la compilacion distribui- 
da en redes. En lugar de que todas las compilaciones se lleven a cabo en una sola ma- 
quina, los constructores de sistemas buscan los procesadores desocupados sobre la red 
y seleccionan varios compiladores en paralelo. Esto reduce notablemente el tiempo re- 
querido para construir un sistema. 

4. Gestion de los objetos derivados. Los objetos derivados son objetos que se crean a par- 
tir de otros objetos fuente. La gestion de los objetos derivados vincula el codigo fuen- 
te y los objetos derivados y solo vuelve a derivarun objeto cuando se requiere por los 
cambios del codigo fuente. 

Gestionar los objetos derivados y disminuir la recompilacion se explica mejor utilizando 
un ejemplo sencillo. Consideremos una situacion donde un programa denominado com p se 
crea a partir de los modulos objeto scan.o, syn.o, sem.o y cgen.o. Para cada modulo objeto, 
existe un modulo del codigo fuente (scan.c, syn.c, sem.c y cgen.c). Un archivo de declara- 
ciones denominado defs.h es compartido por scan.c, syn.c y sem.c (vease la Figura 29.10). 
En la Figura 29.10 las flechas significan «depende de». Por lo tanto, com p depende de scan.o, 
syn.o, sem.o y cgen.o, scan.o dependen de scan.c, etcetera. 



Figura 29.10 
Dependencias entre 
componentes. 
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Si scan.c cambia, la herramienta de construccion del sistemapuede detectarque el objeto 
derivado scan.o debe reconstruirse y llamar al compilador de C para compilar scan.c con el 
fin de crearun nuevo objeto derivado, scan.o. 

Despues la herramienta de construccion utilizael vinculo de dependencia entre comp y 
sc a n . o para detectar que comp debe reconstruirse vincul ando scan.o, syn.o,sem.oycgen.o. 
El sistemapuede detectarque los otros componentes del codigo objeto no cambiaron, por lo 
que no es necesaria la recompilacion del codigo fuente asociado. 

Algunos constructores de sistemas utilizan el archivo de la fecha de modificacion como 
atributo clave para decidir si se requiere la recompilacion. Si un archivo de codigo fuente se 
modifica despues de su correspondiente archivo de codigo objeto, entonces este ultimo se re- 
construye. Esto normalmente significa que existe un objeto derivado solo para la version del 
codigo fuente mas reciente. Cuando se crea una nueva version del codigo objeto la version 
anterior de este se pierde. 

Otros sistemas utilizan un enfoque mas sofisticado para derivar la gestion de los objetos. 
Agregan objetos derivados al identificador de la version del codigo fuente utilizado para ge- 
nerar estos objetos. Dentro de los limites de la capacidad de almacenamiento, conservan to- 
dos los objetos derivados. Porlo tanto, generalmente es posible recuperar el codigo objeto de 
todas las versiones de los componentes del codigo fuente sin recompilacion. 
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Configuration Management Principles and Practice. Es un estudio extenso que incluye los estandares y las aproxi- 
maciones tradicionales de la CM, asi como aproximaciones de la CM que son mas adecuadas para los procesos mo- 
dernos como el desarrollo agil de software. (A. M. J. Hass, 2002, Addison- Wesley.) 

«A layered architecture for uniform version management)). Este articulo analiza las diferentes aproximaciones a la 
gestion de versiones del software y propone un modelo basico que puede adaptarse a todas ellas. Incluye un buen 
informe sobre trabajos en esta area. [B. Westfechel et ai, IEEE Transactions on Software Engineering, 27 (12), di- 
ciembre de 2001.] 

«Software Configuration Management: A roadmap». Este articulo presenta una perspectiva sobre la evolucion SMC 
e identifica las investigaciones nuevas en esta area. Q. Estublier, Proc. Int. Conf. on Software Engineering, 2000. IEEE 
Press.) 

Trenas in Software: Configuration Management. Es una coleccion de art iculo s sobre diferentes aspectos de la ges- 
tion de la configuracion escritos por autores que son investigadores y profesionales en este campo. Es una buena 
introduccion para estudiantes y profesionales interesados en leer temas de CM avanzados. [W. Tichy (ed.), 1995, John 
Wileyand Sons.] 



29.1 Explique por que no se debe utilizar el titulo de un documento para identificar dicho documento en un sis- 
tema de gestion de (a configuracion. Sugiera un estandar para un esquema de identificacion de docu- 
mentos que se pueda utilizar para todos los proyectos de una organizacion. 

292 Utilizando el enfoque orientado a objetos (vease el Capitulo 8), disene un modelo de una base de datos 
de configuracion que registre la informacion de los componentes del sistema, las versiones, las entregas 
y los cambios. Algunos requerimientos del modelo de datos son los siguientes: 

• Debe ser posible recuperar todas las versiones o una version especifica de un componente. 

• Debe ser posible recuperar la ultima version de un componente. 

• Debe ser posible saber que peticiones de cambios se implementaron en una version especifica del sis- 
tema. 

• Debe ser posible saber que versiones de los componentes se incluyeron en una version especifica de 
un sistema. 

• Debe ser posible recuperar una version particular de un sistema segun su fecha de entrega o de acuer- 
do con los clientes a quienes se les hizo la entrega. 

29.3 Utilizando un diagrama de flujo de datos, describa un procedimiento de gestion de cambios que se pueda 
utilizar en una organizacion grande que se dedique a desarrollar software para clientes externos. Los cam- 
bios se pueden sugerir de fuentes externas o internas. 

29.4 ^,C6mo el uso de sistemas de gestion de versiones basado en proyectos como CVS simplifica el proceso de 
gestion de versiones? 

29.5 Explique por que en un sistema de identificacion de versiones basada en atributos es mas facil descubrir 
todos los componentes utilizados en una version especifica del sistema. 
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29.6 Describa lasdificultadesquepueden aparecer enlaconstruccionde sistemas. Indique tos problem as par- 
ticulars que surgen cuando se construye un sistema sobre una computadora y el programa se va a eje- 
cutar en otra maquina especifica. 

29.7 Con referenda a la construction de sistemas, explique por que algunas veces es necesario conservar los 
ordenadores obsoletos sobre las cuales se desarrollaron los sistemas de software. 

29.8 Unproblemacomun enlaconstruccionde sistemas ocurre cuando los nombres de los archivos f is i cos se 
incorporan al codigo del sistema y la estructura del archivo implicada en esos nombres difiere de la es- 
tructura de la maquina en que se ejecutara. Redacte un conjunto de guias para el programador que ayu- 
den a evitar este y otros problemasen laconstruccion de sistemas. 

29.9 Describa cinco factores que deben teneren cuenta los ingenieros durante el proceso de construccion y en- 
trega de un sistema de software grande. 

29.10 Describa dos formas en las cuales las herramientas de construccion de sistemas pueden optimizar el pro- 
ceso de construccion de una version de un sistema a partir de sus componentes. 



Ada 

Lenguaje de programacion que file desarrollado por el Departamento de Defensa de los Es- 
tados Unidos como un lenguaje estandar para el desarrollo de software militar. Esta basado 
en las investigaciones en los lenguajes de programacion a partirde los anos 70 e incluye cons- 
trucciones como los tipos abstractos de datos y soporte para concurrencia. Todavia se utiliza 
en grandes sistemas aeroespaciales militares complejos. 

analisis estatico 

Analisis basado en herramientas del codigo fuente de un programa para descubrir errores y 
anomalias, Las anomalias como las asignaciones sucesivas a una variables sin un uso inter- 
medio pueden ser errores de programacion. 

arquitectura cliente-servidor 

Modelo arquitectonico para sistemas distribuidos en el que la funcionalidad del sistema se 
ofrece como un conjunto de servicios proporcionados porun servidor. Estos son accedidos por 
computadoras cliente que hacen uso de los servicios. Variantes de este enfoque, como las ar- 
quitecturas cliente-servidor de tres capas, utilizan multiples servidores. 

arquitectura de referenda 

Arquitectura generica del sistema que es una arquitectura idea) que incluye todas las caracte- 
risticas que los sistemas podrian incorporar. Constituye un modo de informar a los disenado- 
res sobre la estructura general de esa clase de sistemas. 

arquitectura software 

Modelo de la estructura y organizacion fundamental de un sistema software, 
banco de trabajo CASE 

Conjunto integrado de herramientas CASE que trabajan conjuntamente para apoyar una acti- 
vidad del proceso importante como el diseno del software o la gestion de la configuracion. 
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C 

Lenguaje de programacion que fue originalmente desarrollado para ayudar a implementar el 
sistema Unix. C es un lenguaje de implementacion de sistemas de relativamente bajo nivel que 
permite el acceso al hardware del sistema y que puede ser compilado a un codigo eficiente. 
Todavia se utiliza ampliamente para la programacion sistemas de bajo nivel. 

C + + 

Lenguaje de programacion orientado a objetos. C es un subconjunto de C++, 
caso de conf iabilidad 

Documento estructurado que se utiliza para apoyar las afirmaciones efectuadas por un desa- 
rrolladordel sistema sobre la confiabilidad de un sistema. 
caso de seguridad 

Argumento estructurado de que un sistema es seguro. Normalmente es requerido por regula- 
dores tales como los reguladores de la seguridad nuclear. 

caso de uso 

Especificacion de un tipo de interaccion con un sistema, 
ciclo de vida del software 

Utilizado a menudo como otro nombre para el proceso del software. Originalmente acufiado 
para referirse al modelo en cascada del proceso del software, 
clase de objetos 

Una clase de objetos define los atributos y operaciones de los objetos. Los objetos se crean 
en tiempo de ejecucion mediante la instanciacion de la definicion de la clase. El nombre de 
la clase de objetos se puede utilizar como un nombre de tipo en algunos lenguajes orientados 
a objetos. 

C M M I 

Enfoque integrado para el modelado de madurez de la capacidad del proceso. Apoya los mo- 
delados de madurez discretos y continuos e integra sistemas y modelos de madurez de los pro- 
cesos de la ingenieria del software. 

codigo de etica y practica profesional 

Conjunto de pautas que exponen el comportamiento etico y profesional esperado de los in- 
genieros del software. Fue definido por las sociedades profesionales principales de los Esta- 
dos Unidos (la ACM y la IEEE) y define el comportamiento etico conforme a ocho titulos: 
publico, cliente y empleador, producto, juicio, gestion, colegas, profesion y personal. 

CO M + 

Un modelo de componentes disenado para su uso en plataformas Microsoft. 
Common Request Broker Architecture (CORBA) 

Conjunto de estandares propuesto por el O M G que define un modelo de objetos distribuido y 

las comunicaciones de los objetos. 

componente 

Unidad de software independiente y desplegable que se ha definido completamente y a la que 
se accede a traves de un conjunto de interfaces. 

confiabilidad 

La confiabilidad de un sistema es una propiedad total que tienen en cuenta la seguridad del 
sistema, la fiabilidad, la disponibilidad, la proteccion y otros atributos. La confiabilidad de un 
sistema refleja el grado en el cual los usuarios pueden confiar en el sistema. 
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construed on del sistema 

Proceso de compilar los componentes o unidades que forman un sistema y enlazarlos con 
otros componentes para crear un programa ejecutable. La construccion del sistema esta nor- 
malmente automatizada de modo que se minimiza la recompilacion. Esta automatizacion 
puede ser incorporada a un sistema de procesamiento de lenguajes (como en Java) o puede 
implicarherramientasC A S E para apoyar la construccion del sistema. 

Constructive Cos! Modelling (COCOMO) 

Quizas el modelo algoritmico de estimacion de costes mas conocido, 
control de la calidad (QC) 

Proceso de asegurarque un equipo de desarrollo de software sigue los estandares de calidad, 
desarrollo del software orientado a aspectos 

Enfoque para el desarrollo de software que combina el desarrollo generativo y el basado en 

componentes. Se identifican los intereses compartidos en un programa y la implementacion 

de estos intereses se define como aspectos. Un programa se encarga entonces de entrelazar 

los aspectos en los lugares apropiados en el programa. 
desarrollo incremental 

Enfoque para el desarrollo de software en el que este se entrega y utiliza en incrementos, 
desarrollo iterativo 

Enfoque para el desarrollo de software en el que se entrelazan los procesos de especificacion, 
diseno, programacion y pruebas. 
desarrollo orientado a objetos (00) 

Enfoque para el desarrollo de software en el que las abstracciones fundamentales en el siste- 
ma son objetos independientes. Se utiliza el mismo tipo de abstraccion durante la especifica- 
cion, diseno y desarrollo. 
desarrollo rapido de aplicaciones (RAD) 

Enfoque para el desarrollo de software dirigido a la entrega rapida de este. A menudo impli- 
ca el uso de la programacion de bases de datos y herramientas de apoyo al desarrollo como 
los generadores de informes y pantallas. 
deteccion dedefectos 

Utilizacion de procesos y comprobaciones en tiempo de ejecucion para detectar y eliminar los 
defectos en un programa antes de que estos causen un fallo de funcionamiento del sistema. 

diagrama de secuencia 

Diagrama que muestra la secuencia de interacciones necesarias para completar alguna opera- 
cion. En U M L , los diagramas de secuencias se pueden asociar con los casos de uso. 

dinamica de evolucion de los program as 

Estudio de las formas en las que cambia un sistema software que se desarrolla, 
diseno de interfaces de usuario 

Proceso de disefiar el modo en el que los usuarios del sistema acceden a la funcionalidad del 
sistema y la forma en la que se visualiza la informacion producida por el sistema. 
disponibilidad 

Preparacion de un sistema para entregar servicios cuando se le soliciten. La disponibilidad 
normalmente se expresa como un numero decimal; asi una disponibilidad de 0,999 significa 
que el sistema puede entregar servicios durante 999 de cada 1 .000 unidades de tiempo. 
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dominio 

Problema o areade negocio especifico donde son utilizados los sistemas software. Ejemplos 
de dominios son el control en tiempo real, el procesamiento de datos de negocio y la conmu- 
tacion de telecomunicaciones. 

elemento de conf iguraclon 

Unidad legible por la maquina, como un documento o un fichero de codigo fuente, que es sus- 
ceptible de cambiary donde los cambios tienen que ser controlados por un sistema de gestion 
de la configuracion. 

enterprise java beans (EJB) 

Modelo de componentes basado en Java. 

entrega 

Version de un sistema software que se pone a disposicion de los clientes del sistema, 
escenario 

Descripcion de una forma tipica en la que se utiliza un sistema o un usuario lleva a cabo al- 
gunaactividad. 

especificacion formal, algebraica 

Metodo de especificacion matematica de sistemas en el que un sistema o componente se es- 
pecifica definiendo las relaciones entre las operaciones definidas en sus interfaces extemas. 

especificacion formal, basada en modelos 

Metodo de especificacion matematica de sistemas en el que un sistema o componente se es- 
pecifica definiendo las precondiciones, postcondiciones e invariantes que se aplican al esta- 
do del sistema. 

etnografi'a 

Tecnica basada en la observacion que puede ser utilizada en la obtencion y analisis de requeri- 
mientos. El etnografo se sumerge en el entorno del usuario y observa sus habitos de trabajo coti- 
dianos. A partir de estas observaciones se pueden deducir requerimientos para apoyo al software. 

evitacion de defectos 

Desarrollo del software de tal modo que no se introduzcan defectos en ese software, 
familia de aplicaciones 

Conjunto de programas de aplicaciones software que tienen una arquitectura comun y una 
funcionalidad generica. Estos se pueden adaptar a las necesidades especificas de los clientes 
modificando componentes y parametros de los programas. 
Habilidad 

Capacidad de un sistema para entregar los servicios como se especifican. La fiabilidad se pue- 
de especificar cuantitativamente como la probabilidad de que ocurra un fallo de funciona- 
miento o como la tasa de ocurrencia de estos. 

garantia de la calidad (QA) 

Proceso general de definir como lograr la calidad del software y como la organizacion de desa- 
rrollo conoce el nivel de calidad requerido en el software. 

generador de programas 

Programa que genera otro programa a partir de una especificacion abstracta de alto nivel. El 
generador incorpora conocimientos que se reutilizan en cada actividad de generacion. 
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gestidn de la configuracion 

Proceso de gestionar los cambios a un producto software que se desarrolla. La gestion de la 
configuracion implica la planificacion de la configuracion, la gestion de versiones, la cons- 
truccion del sistema y la gestion del cambio. 

gestion de requerimientos 

Proceso de gestionar los cambios en los requerimientos para asegurar que los cambios efec- 
tuados son correctamente analizados e implementados en el sistema. 

gestion de riesgos 

Proceso de identificar los riesgos, evaluar su gravedad, planificar las medidas a adoptar si se 
presenta el riesgo y supervisar el software y los procesos software para los riesgos. 

grafico de actividades (PERT) 

Grafico utilizado por los gestores de proyectos para mostrar las dependencias entre las tareas 
que se tienen que completar. El grafico muestra las tareas, el tiempo esperado para comple- 
tarlas y las dependencias entre ellas. El camino critico es el camino mas largo (en funcion del 
tiempo requerido para completar las tareas) a lo largo del grafico de actividades. El camino 
critico define el tiempo minimo requerido para completar el proyecto. 

grafico de barras (Gantt) 

Grafico utilizado por los gestores de proyectos para mostrar las tareas del proyecto, la agen- 
da asociadacon estas tareas y las personas que trabajaran en ellas. Muestra las fechas de co- 
mienzo y finalizacion de las tareas y la asignacion de personal contra una linea de tiempo. 

herramienta CASE 

Herramienta software, como un editor del diseno o un depuradorde programas, utilizadapara 
apoyar una actividad en el proceso de desarrollo del software. 

ingenieria de sistemas 

Proceso que trata de la especificacion de un sistema, la integracion de sus componentes y las 
pruebas de que el sistema cumple sus requerimientos. La ingenieria de sistemas no solo trata 
el sistema software, sino el sistema socio-tecnico entero: software, hardware y procesos ope- 
rativos. 

Ingenieria del Software Asistida por Computadora (CASE) 

Proceso de desarrollar software utilizando ayuda automatizada. 

ingenieria del software basada en componentes (CBSE) 

Desarrollo de software a partir de la composicion de componentes independientes y desple- 
gabas. 

ingenieria del software de sala limpia 

Enfoque para el desarrollo de software en el que el objetivo es evitar introducir defectos en el 
software (por analogia con una sala limpia utilizada en la fabricacion de semiconductores). 
El proceso implica la especificacion formal del software, la transformacion estructurada de 
una especificacion a un programa, el desarrollo de argumentos de la correccion y pruebas es- 
tadisticas de programas. 

inspeccion de programas 

Proceso de verificacion en el que un grupo de revisores examina un programa, linea por linea, 
con el objetivo de detectar errores. 
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Intcrfaz de Programacion de Aplicaciones (API) 

Interfaz, generalmente especificada como un conjunto de operaciones, definida por un pro- 
grama de aplicacion que permite acceder a la funcionalidad del programa. Esto significa que 
no solo se puede acceder a esta funcionalidad a traves de la interfaz de usuario, sino que otros 
programas pueden utilizarla directamente. 

interfaz 

Especificacion de los atributos y operaciones asociados con un componente software. La in- 
terfaz es utilizada como el medio de teneracceso a la funcionalidad del componente. 

ISO 9000 

Estandar para los procesos de gestion de calidad definido por la Organizacion Internacional 
de Normalizacion (ISO). 

Java 

Lenguaje de programacion orientado a objetos que fue disenado por Sun con el objetivo de la 
independencia de la plataforma. 

Lenguaje de Modelado Unificado (UML) 

Lenguaje grafico utilizado en el desarrollo orientado a objetos que incluye varios tipos de mo- 
delos del sistema que proporcionan distintas vistas de un sistema. U M L se ha convertido en 
un estandar defacto para el modelado orientado a objetos. 

lenguaje de restricciones de objetos (OCL) 

Lenguaje que forma parte de U M L , utilizado para definir predicados que se aplican a las cla- 
ses de objetos e interacciones en un modelo UML. 

Lenguaje Estructurado de Consultas (SQL) 

Lenguaje estandar utilizado para laprogramacion de bases de datos relacionales . 

linca de productos software 

Vease familia de aplicaciones. 

mantenimiento 

Proceso de hacer cambios en un sistema despues de que este en funcionamiento, 
marcos de trabajo de aplicaciones 

Estructura generica en algun dominio especifico que puede formar la base de una familia de 
aplicaciones. Los marcos de trabajo de aplicaciones generalmente se implementan como un 
conjunto clases concretas y abstractas especializadas e instanciadas para crear una aplica- 
cion. 

mejora de procesos 

Proceso de hacer cambios a un proceso con el objetivo de hacerlo mas previsible o mejorar la 
calidad de sus salidas. Por ejemplo, si su objetivo es reducirel numero de defectos en el soft- 
ware entregado, podria mejorar el proceso anadiendo nuevas actividades de validacion. 

metodo estructurado 

Metodo de diseno de software que define los modelos del sistema que se deben desarrollar, 
las reglas y pautas que se deben aplicar a estos modelos y un proceso a seguir en el desarro- 
llo del diseno. 

metodos agfles 

Metodos de desarrollo de software dirigidos a la entrega rapida del mismo. El software se de- 
sarrolla y entrega en incrementos, y se minimiza el proceso de documentacion y laburocracia. 
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metodos formales 

Metodos de desarrollo de software basados en enfoques matematicamente rigurosos que mo- 
delan el software utilizando construcciones matematicas formales como predicados y con- 
juntos. 

metrica software 

Atributo de un sistema o proceso software que se puede medir o expresar numericamente . Las 
metricas de procesos son atributos del proceso como el tiempo necesario para completar una 
tarea; las metricas de productos son atributos del software mismo como el tamafio o la com- 
plejidad. 

middleware 

Infraestructura software en un sistema distribuido. Ayuda a gestionar las interacciones 
entre las entidades distribuidas en el sistema y las bases de datos del mismo. Ejemplos de 
middleware son un intermediario de peticiones de objetos y un sistema de gestion de trans- 
acciones. 

modelado algoritmico de costes 

Enfoque para la estimacion del coste del software en el que se utiliza una formula para esti- 
mar el coste del proyecto. Los parametros en la formula son atributos del proyecto y el soft- 
ware mismo. 

modelado del aumento de la fiabilidad 

Desarrollo de un modelo de como cambia la fiabilidad de un sistema (se espera que mejore) 
conforme este se prueba y eliminan los defectos de los programas. 

modelo de componentes CORBA 

Modelo de componentes disenado para su uso para plataformas CORBA. 
modelo de componentes 

Conjunto de estandares para la implementacion, documentacion y utilizacion de componen- 
tes. Estos cubren las interfaces especificas que pueden serproporcionadasporun componen- 
te, el nombrado de componentes, la interoperatividad de los componentes y la composicion 
de estos. Los modelos de componentes proporcionan la base al middleware para soportar la 
ejecucion de componentes. 

Modelo de Madurez de la Capacidad del Personal (P-CMM) 

Modelo de madurez del proceso que refleja como de efectiva es una organizacion gestionan- 
do las habilidades, formacion y experiencia del personal de esa organizacion. 

modelo de madurez del proceso 

Modelo del grado en el que un proceso incluye buenas practicas y capacidades de medida y 
reflexivas que estan orientadas a la mejora de procesos. 

modelo de objetos 

Modelo de un sistema software que se estructura y organiza como un conjunto de clases de 
objetos y las relaciones entre estas clases. Pueden existir varias perspectivas diferentes en el 
modelo, como una perspectiva del estado y una perspectiva de la secuencia. 

modelo de procesos 

Representacion abstracta de un proceso. Los modelos de procesos pueden ser representados 
desde varias perspectivas y mostrar las actividades implicadas en un proceso, los objetos uti- 
lizados en el proceso, las restricciones que se aplican al proceso y los roles de las personas in- 
volucradas en el proceso. 
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modelo del dominio 

Definicion de abstracciones del dominio como politicas, procedimientos, objetos, relaciones 
y eventos. Sirve de base de conocimiento sobre alguna area del problema. 

modelo en cascada 

Modelo del proceso del software en el que existen diferentes etapas de desarrollo: especifi- 
cacion, diseno, implementacion, pruebas y mantenimiento. En principio, se debe completar 
una etapa antes de que se pueda avanzar a la siguiente. En la practica, existe iteracion entre 
las etapas. 

modelo en espiral 

Modelo de un proceso de desarrollo donde el proceso se representa como una espiral en la que 
cada vuelta de la espiral incorpora las diferentes etapas en el proceso. Si se pasa de una vuel- 
ta de la espiral a otra, se repiten todas las etapas del proceso. 

Object Management Group (OMG) 

Grupo de companias formado para desarrollar estandares para el desarrollo orientado a obje- 
tos. Ejemplos de estandares promovidos por el OMG son CORBA, UML y MDA. 

ocultacion de information 

Utilizacion de construcciones de lenguajes de programac ion para ocultar la representacion de 
las estructuras de datos y controlar el acceso externo a estas estructuras. 

patron de diseno 

Solucion probada a un problema comun que capta las experiencias y buenas practicas de una 
forma que puede ser reutilizada. Es una representacion abstracta que se puede instanciar de 
varias formas. 

plan de calidad 

Plan que define los procesos y procedimientos de calidad que se deben utilizar. Implica se- 
leccionare instanciar estandares para productos y procesos y definir los atributos de la cali- 
dad requeridos del sistema. 

principios de diseno de las interfaces de usuario 

Conjunto de principios que expresan buenas practicas para el diseno de interfaces de usuario, 
proceso del software 

Conjunto relacionado de actividades y procesos implicados en el desarrollo y evolucion de un 
sistema software. 

Proceso Unificado de Rational (RUP) 

Modelo de proceso del software generico que presenta el desarrollo del software como una 
actividad iterativa de cuatro fases que son inicio, elaboracion, construccion y transicion. La 
fase de inicio establece un caso de negocio para el sistema, la fase de elaboracion define la ar- 
quitectura, la de construccion implementael sistema y lade transicion utiliza el sistema en el 
entorno del cliente. 

programacion extrema (XP) 

Metodo agil de desarrollo de software que incluye practicas como los requerimientos basa- 
dos en escenarios, el desarrollo previamente probado y la programacion en parejas. 

propiedad emergente 

Propiedad que solo se hace evidente una vez que se han integrado todos los componentes del 
sistema para crearlo. 
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proteccion 

Capacidad de un sistema para protegerse contra intrusiones accidentales o premeditadas, 
prototipado Mago de Oz 

Enfoque para el prototipado de las interfaces de usuario en el que los comandos introducidos por 
los usuarios son interpretados por una persona quien responde como si fuera la computadora. 

reingenieria, proceso de negocio 

Cambio de un proceso de negocio para cumplir algun objetivo organizacional nuevo como la 
reduccion de costes y la ejecucion mas rapida. 

reingenieria 

Modificacion de un sistema software para hacerlo mas facil de comprendery cambiar. La rein- 
genieria a menudo implica la reestructuracion y organizacion de datos y software, la simpli- 
ficacion de programas y la redocumentacion. 

requerimiento de confiabilidad 

Requerimiento del sistema que se incluye para ayudar a alcanzar la confiabilidad requerida 
para un sistema. Los requerimientos de confiabilidad no funcionales especifican los valores 
de los atributos de la confiabilidad; los requerimientos de confiabilidad funcionales son re- 
querimientos funcionales para evitar, detectar, tolerar o reponerse de defectos y fallos de fun- 
cionamiento del sistema. 

requerimiento, funcional 

Declaracion de alguna funcion o caracteristica que se debe implementar en un sistema, 
requerimiento, no funcional 

Declaracion de una restriccion o comportamiento esperado que se aplica a un sistema. Esta 
restriccion se puede referir a las propiedades emergentes del software que se esta de- 
sarrollando o al proceso de desarrollo. 
riesgo 

Resultado indeseable que supone una amenaza para conseguir algun objetivo. Un riesgo del 
proceso amenaza la agenda o coste de un proceso; un riesgo del producto es un riesgo que pue- 
de significar que no se consigan algunos de los requerimientos del sistema. 

seguridad 

Capacidad de un sistema para funcionar sin fallos de funcionamiento catastroficos, 
servicio web 

Componente software independiente al que se puede acceder a traves de Internet utilizando 
protocolos estandares. SOAP (Simple Object Access Protocol) se utiliza para el intercambio 
de informacion en servicios web. WSDL (Web Service Description Language) se utiliza para 
definir las interfaces de los servicios web. 
servidor 

Programa que proporciona algun servicio a otros programas (clientes), 
sistema critico 

Sistema informatico cuyo fallo de funcionamiento puede causar importantes perdidas econo- 
micas, humanas o medioambientales. 
sistema de objetos distribuidos 

Sistema distribuido en el que los componentes ejecutables son objetos. 
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sistema de procesamiento de datos 

Sistemacuyo proposito es procesar grandes cantidades de datos estructurados. Estos sistemas 
normalmente procesan los datos por lotes y siguen un modelo de entrada-proceso-salida. 
Ejemplos de sistemas de procesamiento de datos son los sistemas de cuentas y facturas, y los 
sistemas de pago. 

sistema de procesamiento de lenguajes 

Sistema que traslada un lenguaje a otro. Por ejemplo, un compilador es un sistema de proce- 
samiento de lenguajes que traslada el codigo fuente de un programa a codigo objeto. 

sistema de procesamiento de transacciones 

Sistema que asegura que las transacciones se procesan de tal forma que no se interfieren en- 
tre si y de modo que el fallo de una transaccion individual no afecte a otras transacciones o a 
los datos del sistema. 

sistema de tiempo real 

Sistema que tiene que responder a eventos extemos y procesarlos en «tiempo real». La co- 
rreccion del sistema no solo depende de lo que hace sino tambien de la velocidadcon que lo 
hace. Los sistemas de tiempo real normalmente se organizan como un conjunto de procesos 
concurrentes que cooperan entre si. 

sistema distribuido 

Sistema software en el que los subsistemas o componentes software se ejecutan en diferentes 
procesadores. 

sistema heredado 

Sistema socio-tecnico que es util o fundamental para una organizacion, pero que ha sido des- 
arrollado utilizando una tecnologia o metodos obsoletos. Debido a que los sistemas hereda- 
dos a menudo llevan a cabo funciones de negocio criticas, tienen que ser mantenidos. 

sistema peer-to-peer 

Sistema distribuido en el que no hay distincion entre clientes y servidores. Las computadoras 
en el sistema pueden actuar como clientes y como servidores. Entre las aplicaciones peer-to- 
peer se incluyen la comparticion de ficheros, los sistemas de mensajeria instantaneay los sis- 
temas de soporte a lacooperacion. 

sistema socio-tecnico 

Sistema, incluidos componentes hardware y software, que ha definido los procesos operati- 
ves seguidos por los operadores humanos y que funciona dentro de una organizacion. Por lo 
tanto, esta influidos por las politicas, procedimientos y estructuras de la organizacion. 

sistemas basados en eventos 

Sistemas en los que el control del funcionamiento se determina por eventos generados en el en- 
torno del sistema. La mayoria de los sistemas de tiempo real son sistemas basados en eventos. 

tipo abstracto de datos 

Tipo cuya representacion se oculta y esta definido por sus operaciones, 
tolerancia a defectos 

Capacidad de un sistema para continuar en ejecucion incluso despues de que hayan tenido lu- 

gar defectos. 

transaccion 

Unidad de interaccion con un sistema informatico. Las transacciones son independientes y 
atomicas (no se pueden dividir en unidades mas pequenas) y son una unidad fundamental de 
recuperacion, consistencia y concurrencia. 
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validacion 

Proceso de verificar que un sistema cumple las necesidades y expectativas del cliente, 
verificacion 

Proceso de verificar que un sistema cumple su especificacion. 
XML 

Lenguaje de Marcado Extensible. X M L es un lenguaje de marcado de texto que soporta el 

intercambio de datos estructurados. Cada campo de datos se delimita por etiquetas que pro- 

porcionan informacion sobre ese campo. X M L se utiliza ampliamente en la actualidad y se 

ha convertido en la base de los protocolos para los servicios web. 
Z 

Lenguaje de especificacion formal basado en modelos desarrollado en la Universidad de Ox- 
ford en Inglaterra. 

Estan disponibles definiciones de otros muchos terminos en el glosario en linea accesible a 
traves del sitio web del libro. 
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